2009/7/6 P.J. Eby <p...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com