Re: Trying to contribute packages: ./pre-inst-env doesn't work

[Gábor Boskovits]

Hello,

Doron Behar <address@hidden> ezt írta (időpont: 2019. máj. 15., Sze,
11:47):

> Thanks for the quick reply!
>
> On Wed, May 15, 2019 at 10:46:29AM +0200, Gábor Boskovits wrote:
> > >
> > It might be easier to first set up a channel with your packages only. You
> > can find
> > several examples out there.
> > Here is one of my channels:
> > https://gitlab.com/g_bor/nominatim-channel
>
> Oh right, thanks. That's an excellent reference.
>
> > >
> > > - I ran ./configure inside /var/code/doron/guix
> > >
> >
> > Did you specify your localstatedir to configure?
>
> Yes, I've given it the same flags I gave it when I've build it at first.
>
> > Did you also run make?
>
> No! I was hoping I could avoid that as that's extremely CPU intensive..
> Is there a way to run make with only the relevant targets? That could be
> very helpful...
>
> Plus, do I have to run make after every change to a package definition!?
> Will it compile everything from the ground up after every such change? I
> wish these technical details would have been documented...
>
>
No, you don't need to do that. Guix will interpret the changed sources, and
it will add a warning that the source file is newer.


> I'm running make while I'm writing this email and I must say that not
> only it takes a lot of time and uses a lot of CPU power, it handles way
> too much irrelevant things such as translations.
>
> I also noticed it runs GUILEC - is it really necessary? I'm no Guile
> expert and I wish I could avoid diving to the whole ecosystem of it just
> because I want to use Guix and contribute some packages!
>
> I talked about this subject in a different thread: The design choice of
> putting all package definitions in the same repository as the package
> manager it self is very uncommon in the Linux. I understand that almost
> all of Guix is written in Guile so it must be linked somehow to the
> package definitions but I think it makes it very hard to actually
>

The channels mechanism actually makes it possible to split off any
part of the packages. So there is no limitations in moving most of
the packages definitions out of guix. I am not familiar enough to
tell if all package definitions could be moved into channels, but for
most of them this could be done.

Could you elaborate on the benefits of doing that?
I guess this could be a great topic of discussion.


> contribute something to the packages definitions! It seems that we,
> package maintainers, or to put it simply - the community, need to be too
> much involved in the source code of everything in order to help the
> distributions. That's rather unfortunate IMHO. I'd like to be convinced
> I'm wrong at least in this subject because as I dive more and more into
> Guix I feel there have been made a lot of poor design choices in it..
>
> >
> > Are your packages in a separate file?
> > If yes, did you add it to local.mk?
>
> No, I've added new definitions to existing files.
>

Ok, then that is not the problem.


>
> > > -----
> > >
> > > Failing to do that and after looking for alternative ways to create new
> > > packages, I read about the `--load-path` option of `guix build`. Is it
> > > possible to use it for new packages testings? I tried to run the
> > > following but I got all kinds of warnings and errors:
> > >
> > > guix build -L/var/code/doron/guix my-new-package
> > >
> > >
> > I would not do that, the channel mechanism superseded this.
>
> I see, makes sense.
>
> > > Here is all of the output:
> > > https://gist.github.com/doronbehar/38d31142522fd01a67e7da412b0cf5ed
> > >
> > > Since there were all of these "source file newer than compiled"
> > >
> >
> > These are actually harmless, they indicate that your .go files should be
> > regenerated, as they are older than the .scm files. You can run make to
> > get rid of these. (Have not looked at the error, tough)
>
> Oh right, makes sense in accordance to your previous comment on running
> make.
>
> >
> >
> > > messages, I tried putting back my channels configuration from above and
> > > run `guix pull` again but I got pretty much the same errors and
> > > warnings.
> > >
> > > -----
> > >
> > > Any way, I'm very frustrated. Although I'm very excited as for the
> > > genius design of Guix and it's flexibility and extensibility, I'm very
> > > disappointed by it's UX for a simple thing as package contribution. but
> > > this should be addressed in a separate discussion
> >
> > .
> > >
> >
> > I am very sorry to hear that. I hope you can point us to the right
> > directions
> > to make this easier. Suggestions about documentation are also very
> welcome.
>
> Oh right. When I'll actually understand everything hopefully with your
> guidance, I hope I'll find the time to send some patches.
>
> Doron.
>
>
Best regards,
g_bor