From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: Replacing Bower with "guix environment" Date: Mon, 27 Apr 2015 08:15:51 -0500 Message-ID: <87r3r5iu33.fsf@earlgrey.lan> References: <87tww2i6je.fsf@earlgrey.lan> <877fsx94rs.fsf@fsf.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmizP-0007HH-AE for guix-devel@gnu.org; Mon, 27 Apr 2015 09:22:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmizN-0003C6-Ug for guix-devel@gnu.org; Mon, 27 Apr 2015 09:22:23 -0400 Received: from [2600:3c02::f03c:91ff:feae:cb51] (port=54220 helo=dustycloud.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmizN-0003BZ-Pn for guix-devel@gnu.org; Mon, 27 Apr 2015 09:22:21 -0400 In-reply-to: <877fsx94rs.fsf@fsf.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: David Thompson Cc: guix-devel David Thompson writes: > Christopher Allan Webber 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!