Re: Replacing Bower with "guix environment"

[Christopher Allan Webber <cwebber@dustycloud.org>]

David Thompson writes:

> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>
>> Hello all,
>>
>> I'm interested in "guix environment" as a universal solution for
>> virtualenv/bower/etc.  There's good reasons to want this; aside from
>> Guix being awesome, packaging for web applications is getting more and
>> more insane and often involves many layers of package management, often
>> *multiple language package managers at once*.  It's a sad state of
>> affairs.
>
> Agreed, it's terrible.  A modern web application typically requires
> *four* separate package managers:
>
> * The system package manager (apt, yum, guix, etc.)
> * The server-side language package manager (pip, gem, etc.)
> * The static asset package manager (bower)
> * The server-side JavaScript package manager (npm)

Yes you're right... the situation is worse than I even painted it to be!

[ ... snip ... ]

>> Dave Thompson has made what I think is probably a good suggestion: there
>> should be some sort of environment variable set with something
>> searchable.  This way, during the "./configure --link-extlib && make" or
>> "python setup.py develop" or whatever such setup-for-development
>> process, there's a way to see, aha here's the jquery, symlink that here;
>> here's the font-awesome, symlink that here; here's the bootstrap,
>> symlink that here...
>
> Yes, something like that.  I think the most important part of any
> solution is that it not be dependent upon Guix tools at all.

This is a really important point!

> Just like Guix isn't needed to find C libraries at configure time.  I
> wouldn't want Guix integrated into web application build systems like
> Bower is.

I agree.  It would be nice for it to be an option, and a highly
desirable one, for development, but that's just because "guix
environment" hopefully could solve this and other problems for
developers so well.  But if someone already had packages installed via
apt/yum/whatever, that should be good enough.

> Even if we come up with a good solution to this problem, Bower is still
> deeply embedded into so many projects.  I wonder if we can be compatible
> with it in any way.

It's possible we could try to read Bower's json description files
somehow, but I doubt it both because package names may be different and
becuase you have the option of calling out with http requests and etc to
pull down files, etc.  The only way to do that in Guix is to read the
file and help figure out how to make pulling down those files happen so
they can become inputs.  I suspect we'd rather link them to standard
files anyway, where possible.

>> I don't know what this environment variable would be called.
>> WEB_ASSETS_PATH?  The other tricky thing is, it's easy to say "put CSS
>> files and jquery in that thing", but what about fonts?  Those have
>> their own location already.  Should both be added to the path?
>
> I need to think about this more.  I should take Bower for a spin and see
> how people are integrating it into their build systems.  How do they
> handle fonts?

Same as any other static asset, they get pulled down and installed
inside the package directory itself.

>> Anyay, I'd love to have a way to do this with Guix.  If someone can find
>> a nice solution, I'll make it an option for development with GNU
>> MediaGoblin instead of using virtualenv/bower. ;)  But we need to know
>> the right path first!
>
> Thanks for starting this discussion.  Let's keep brainstorming!

Yes, it's a good conversation so far, I hope we can find some solutions!