Re: [Python-Dev] PEP 376 - Open questions
At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
+1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of stuff as.)
- What precisely are the use cases for absolute path names? Concrete
examples are needed. With the current spec, some things can go wrong (e.g., see below), so we need real use cases to know how to address this.
The purpose is to be able to remove scripts, data files, documentation, etc. that's stored in some place that's not package-relative, and survive a move of the package directory itself.
For example, suppose I install with --prefix=~, and have files in ~/bin and ~/lib. I then move ~/lib/python2.7 to ~/pylib. If the scripts were installed with a relative path, this would break the link to the script still living in ~/bin.
Now that I'm thinking about this, it occurs to me that there is another way to address this besides mixing relative and absolute paths in RECORD, and that is to make *all* the paths relative, and include an original installation location in INSTALLER. Then, it would be possible to detect whether the installation location had been moved and handle it accordingly... for some definition of "accordingly".
I agree that further discussion is probably needed to resolve this.
- How will bdist_wininst/bdist_msi/bdist_rpm be updated?
bdist_wininst, bdist_dumb, and various others use 'install --root' pattern to generate files for installation, which means that they would transparently end up writing a correct RECORD file, except for the inclusion of incorrect absolute paths for non-libdir-relative files. However, if we used the "all relative in RECORD, with a base in INSTALLER", these cases could transparently be treated as another instance of install directory relocation.
I don't know if bdist_msi does a --root install before generating the .msi; if it does, then it should work the same way.
- Can distutils be made to install files in places the current RECORD
file spec can't handle? (I think the answer is "yes"). What happens then?
Surely an absolute path is sufficient?
- Should distribution names be case insensitive on case insensitive
filesystems? For comparison, module/package names are always case sensitive even on case insensitive systems.
IMO, they should be case-insensitive *regardless* of filesystem case, and I believe PyPI has already begun disallowing packages with only case-distinct names (e.g. 'Zope' vs. 'ZoPe') to be registered.
2009/7/6 P.J. Eby pje@telecommunity.com:
At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
+1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of stuff as.)
Thanks. I think this one is pretty non-controversial.
- What precisely are the use cases for absolute path names? Concrete
examples are needed. With the current spec, some things can go wrong (e.g., see below), so we need real use cases to know how to address this.
The purpose is to be able to remove scripts, data files, documentation, etc. that's stored in some place that's not package-relative, and survive a move of the package directory itself.
For example, suppose I install with --prefix=~, and have files in ~/bin and ~/lib. I then move ~/lib/python2.7 to ~/pylib. If the scripts were installed with a relative path, this would break the link to the script still living in ~/bin.
Now that I'm thinking about this, it occurs to me that there is another way to address this besides mixing relative and absolute paths in RECORD, and that is to make *all* the paths relative, and include an original installation location in INSTALLER. Then, it would be possible to detect whether the installation location had been moved and handle it accordingly... for some definition of "accordingly".
I agree that further discussion is probably needed to resolve this.
I'm not 100% sure I follow your logic here. If you're renaming directories after install, without involving the package manager, I think you probably deserve whatever you get :-)
Having said that, your proposal (all paths relative, plus an install location) is similar to something I mentioned earlier (but better explained :-)) The only case it doesn't cater for is when an installed file can't be expressed as relative to the "install location" (which would involve being on a different drive on Windows). That's likely to never work, so I doubt it counts in any case. I've got some concerns about the possibility of having locations "above" the install location - something like "../../scripts/driver.bat". I'm not sure if such things will work (consider if the install location is a zipfile or egg) but nor am I sure anything generates such names.
As you say, more discussion (and use cases!) would help here.
- How will bdist_wininst/bdist_msi/bdist_rpm be updated?
bdist_wininst, bdist_dumb, and various others use 'install --root' pattern to generate files for installation, which means that they would transparently end up writing a correct RECORD file, except for the inclusion of incorrect absolute paths for non-libdir-relative files. However, if we used the "all relative in RECORD, with a base in INSTALLER", these cases could transparently be treated as another instance of install directory relocation.
I don't know if bdist_msi does a --root install before generating the .msi; if it does, then it should work the same way.
Yes, that sounds like a plausible approach.
- Can distutils be made to install files in places the current RECORD
file spec can't handle? (I think the answer is "yes"). What happens then?
Surely an absolute path is sufficient?
Current spec says relative or $PREFIX/... or $EXEC_PREFIX/...
I think that was based on earlier discussion, but it's hampered by the fact that nobody's pointing at a real case of a distribution that actually tries to *install* files in odd places. (Actually, something that installs a driver script, like twisted's twistd or nose's nosetests, would do - I'll see what I can find tomorrow).
- Should distribution names be case insensitive on case insensitive
filesystems? For comparison, module/package names are always case sensitive even on case insensitive systems.
IMO, they should be case-insensitive *regardless* of filesystem case, and I believe PyPI has already begun disallowing packages with only case-distinct names (e.g. 'Zope' vs. 'ZoPe') to be registered.
OK, that's another option :-) It's not hard to change the code, so as long as a final decision is reached at some point, we're OK here...
Thanks for the comments, Paul.
2009/7/7 Paul Moore p.f.moore@gmail.com:
2009/7/6 P.J. Eby pje@telecommunity.com:
At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
As promised, here are some open questions on PEP 376.
- Will the public API names be changed from *egginfo* to *metadata*?
+1 (FWIW, 'metadata' is what pkg_resources API refers to this kind of stuff as.)
Thanks. I think this one is pretty non-controversial.
+1, I'll change the PEP accordingly;
- How will bdist_wininst/bdist_msi/bdist_rpm be updated?
bdist_wininst, bdist_dumb, and various others use 'install --root' pattern to generate files for installation, which means that they would transparently end up writing a correct RECORD file, except for the inclusion of incorrect absolute paths for non-libdir-relative files. However, if we used the "all relative in RECORD, with a base in INSTALLER", these cases could transparently be treated as another instance of install directory relocation.
I don't know if bdist_msi does a --root install before generating the .msi; if it does, then it should work the same way.
Yes, that sounds like a plausible approach.
As I said earlier in the previous thread, all these commands rely on a call to the install command, so bdist_msi does too.
participants (3)
-
P.J. Eby -
Paul Moore -
Tarek Ziadé