Re: Managing environments (Python venv, guix environment, etc.)

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 26 Jul 2016 05:08:31 +0300
> 
> >> Consider: if we just add a new defgeneric (or two) to project.el, any
> >> specialized environment implementation would either have to provide its
> >> own full project implementation (i.e. it'll be unable to use
> >> vc-project), or it'll have to define specialized implementations of
> >> these methods just for certain types of projects it knows about.
> >
> > Why can't the default implementation behave as if "environments"
> > didn't exist?
> 
> Then those projects will miss out on Guix, and similar, integrations.

I don't understand why.  Can you elaborate?

> My point is, whether a project uses Guix, or a similar tool, should be 
> in vast majority of cases orthogonal to the type of the project 
> (language used, frameworks, configuration file format, etc).
> 
> So far I'm inclined to believe that there should be about as many 
> project implementations as there are project file formats (e.g. Maven, 
> Ant, Autotools, Gradle configs, specialized formats used by other 
> editors, etc). There's no reason to multiply that by the number of 
> environment types we want to support.

Maybe I misunderstand, but I thought requirements for supporting
Maven, Ant, etc., are indeed orthogonal to those imposed by Guix etc.,
so no multiplication should be necessary.  If not, then how do people
use these combinations outside of Emacs -- do they also create all the
combinations?

Maybe we should discuss what is and what isn't part of a "project".