[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Managing environments (Python venv, guix environment, etc.)
Date: Tue, 26 Jul 2016 05:08:31 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Thunderbird/47.0

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]