Christopher Allan Webber <cweb...@dustycloud.org> writes: > David Thompson writes: > >> Christopher Allan Webber <cweb...@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