Re: Replacing Bower with "guix environment"

[David Thompson <dthompson2@worcester.edu>]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> David Thompson writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> writes:
>>

[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.

Yes, people should use Guix for development because it's awesome, not
because software doesn't build without it. ;)

>> 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.

Seems like you're talking about importing.  A 'guix import bower' tool
could be easily written, I think.  We have guile-json, so we can read
the 'bower.json' files and DTRT.  The biggest issue I see is that Bower
doesn't build from source, and people are just checking in minified
JavaScript files to the Git repos that Bower clones.  Our
'bower-build-system' would have to work around this and build from
source.  However, in order to do that, we need a 'node-build-system' so
that we can build the common build tools like Grunt and Uglify.  Are you
still with me or am I going down this rabbit hole alone? ;)

As for build system compatibility, I think that the 'bower_components'
directory structure is quite sane, so it could be a valid
$WEB_ASSET_PATH.

>>> 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.

Thanks.  I confirmed this with a 'bower install bootstrap' (which is a
total mess, btw).

-- 
David Thompson
Web Developer - Free Software Foundation - http://fsf.org
GPG Key: 0FF1D807
Support the FSF: https://fsf.org/donate