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

[Dmitry Gutov <dgutov@yandex.ru>]

On 07/25/2016 08:00 PM, Eli Zaretskii wrote:

>> Couldn't that be fixed?
>
> We try, but it isn't always easy.  Here's one example, from
> file-truename:
>
>       (let ((handler (find-file-name-handler filename 'file-truename)))
> 	;; For file name that has a special handler, call handler.
> 	;; This is so that ange-ftp can save time by doing a no-op.
> 	(if handler
> 	    (setq filename (funcall handler 'file-truename filename)
> 		  done t)
> 	  (let ((dir (or (file-name-directory filename) default-directory))
> 		target dirfile)
> 	    ;; Get the truename of the directory.
> 	    (setq dirfile (directory-file-name dir))
> 	    ;; If these are equal, we have the (or a) root directory.
> 	    (or (string= dir dirfile)
> 		(and (memq system-type '(windows-nt ms-dos cygwin nacl))
> 		     (eq (compare-strings dir 0 nil dirfile 0 nil t) t))
>
> As you see, we only apply the MS-Windows specific treatment to files
> which don't have a handler, on the assumption that those which do are
> not subject to rules that govern local files on MS-Windows.

Maybe default handler implementation could bind the handlers alist to 
nil and call file-truename again.

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

> Then the behavior will be exactly as it is now, no?

It would. That doesn't sound optimal to me.

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.