Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
2009/7/7 Ben Finney : > Paul Moore writes: > >> In fact, the above strongly suggests to me that PEP 376 must NOT >> follow setuptools conventions - otherwise, it will end up clashing >> with the files setuptools is putting on my system. > > I think the argument for a separate ‘.pydist’ metadata directory, > normative in PEP 376, is a good one. I've been convinced otherwise. There's no long-term benefit (the directory layout and format is the same, so it's a purely cosmetic change) and we're doing no favours to anyone just adding a new format for the sake of it. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
On Tue, Jul 7, 2009 at 12:16 AM, Paul Moore wrote: >> >> I believe the idea of having different names in 2.x and 3.x would likely >> cause too many problems for simple bdist_* installers of modules that >> use only the common 2.x/3.x language subset, so I'm also -1 on that idea. > > That suits me too. I'm happy for the name to stay as it is. While I'd rather like having an "egg"-free standard, it's a detail compared to the rest, so I'm 0+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
2009/7/7 Paul Moore : > 2009/7/6 P.J. Eby : >> 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
Paul Moore wrote: > 2009/7/7 Ben Finney : >> Paul Moore writes: >> >>> In fact, the above strongly suggests to me that PEP 376 must NOT >>> follow setuptools conventions - otherwise, it will end up clashing >>> with the files setuptools is putting on my system. >> I think the argument for a separate ‘.pydist’ metadata directory, >> normative in PEP 376, is a good one. > > I've been convinced otherwise. There's no long-term benefit (the > directory layout and format is the same, so it's a purely cosmetic > change) and we're doing no favours to anyone just adding a new format > for the sake of it. The PEP should take the chance to define not only the directory, but also the complete set of files in there and their format. A typical setuptools dir looks like this: dependency_links.txt namespace_packages.txt not-zip-safe PKG-INFO requires.txt SOURCES.txt top_level.txt Ie. a complete mess of upper-case/lower-case names, names with underscores or hyphens as word separator, files with extensions, files without them. This needs some serious cleanup. A new dir name will allow to do this, so +1 on a new dir name. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 07 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
2009/7/7 Paul Moore :
> 2009/7/6 Nick Coghlan :
>> I'd add one more question to the list: is allowing backslash separated
>> names in the RECORD file actually a good idea, or would it be better to
>> always use forward slashes?
>
> They do always use forward slashes.
>
>> For the other questions, I don't have anything much to add to PJE's
>> comments, except that the "all relative" paths idea won't work due to
>> the Windows drive letter issue (i.e. if an installer puts files in
>> C:\Program Files, there is no guarantee that a relative path between
>> site-packages and Program Files even exists if Python is installed on a
>> different drive).
>
> The big question, though, is can an installer actually *do* that in
> practical terms?
>
> - There are *no* guaranteed absolute locations on Windows, so any such
> oddly-located file would require user interaction to work. Certainly
> bdist_wininst and bdist_msi don't do that.
> - My experiments indicate that bdist_{wininst,msi} are broken with
> respect to absolute paths anyway: they do a --root install to a
> temporary directory (and the absolute paths don't end up in there) and
> then package up that temporary directory.
yes that's unfortunately the case for all windows-based installation.
wether it's a bdist call to the install command, to create a binary package,
wether it's an installation.
c:\something or d:\something will be installed in sys.prefix\something.
I will add an issue for distutils for this, probably ending up raising
an exception when we hit this case, because I don't see how these
paths can work.
Unless we define a "drive that contains the python installation" maybe, or
the "Program Files" directory
would that make sense from a win32 point of view ?
>
> I still want to see a real life example that demonstrates that there
> is a genuine issue here. We're spending a lot of energy and complexity
> trying to design a solution to a problem that actually doesn't appear
> to exist in practice...
>
> (To be honest, I'd be fairly confident in saying that absolute paths
> can be ignored on Windows, subject to some corner cases that I haven't
> thought through yet. My worry is that I don't know what Unix and Mac
> users might do, so I can't just wish away the issue because it can't
> arise on Windows. Can a Unix/Mac user offer a real-world example on
> their own system?)
>
I know some people are writing to /etc to add their configuration file
on the system,
So a real-world example under linux would be:
setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
That is basically how the examples are shown at:
http://docs.python.org/distutils/setupscript.html#installing-additional-files
But this is already os-specific, and exists because distutils doesn't
have a way (yet)
to express systems locations independantly from their physical location,
like what the RPM system does with %VARIABLES.
So another way to handle this maybe, like I have added with $PREFIX
and $EXEC_PREFIX
would be to nominate a list of variables that every python environment
has (querying
modules like sys) and let the developers use them as root locations
for some files.
- sys.prefix
- sys.exec_prefix
- some elements returned by distutils.sysconfig.get_config_vars()
(distutils.sysconfig queries the python Makefile amongst others)
- ...
Semi-related: distutils.sysconfig should be removed from distutils,
and be a standalone module in the sdtlib for example.
Regards
Tarek
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
Nick Coghlan wrote: > Martin v. Löwis wrote: >>> I suggest that we also run a version of that redirection filter to remap >>> the old svn.python.org links in addition to making them accessible >>> through hg.python.org as Dirkjan proposed. >> Not sure what links you are talking about, but we also need to keep the >> current svn.python.org up as-is, for all the stuff that won't be migrated. Good point. So the old svn revision links will continue to work. > In that case, no need to redirect anything (although it will still be > possible to look up the old SVN revisions in the Hg web view). > > The previous discussion was based on the assumption that it was going to > be possible to switch the SVN server off at some point rather than just > disallowing commits to the projects that had migrated to Mercurial. Is there a standard notation for hg revisions that roundup could detect and turn into links (much like it does for svn) ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 07 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
On 6 Jul, 2009, at 9:53, Tarek Ziadé wrote: 2009/7/6 Ronald Oussoren : I'm -1 on changing the name. For better or worse setuptools is the elephant in the room w.r.t. package management and it would IMHO be better to stay compatible (even if the stdlib only implements a subset of setuptools/pkg_resources) I'd rather see the elephant evolves. I don't see why we should bend a standard we want to introduce in the stdlib, for a third-party package that is able to evolve to stick to a new standard without any problem. But why break existing code without having any other benifits? If I read the discussion correctly the name would be changed without any changes to the contents of the metadata directory. I would be more inclined to be in favour if the name change had a sound technical reason, such as a change of the contents of the directory which would make setuptools "egg-info" directories incompatible with the PEP376 ones. Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
> Is there a standard notation for hg revisions that roundup could
> detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
(Sorry for my absence from the discussion for some time. I'll try to
update the PEP and summarize ongoing discussions here soon.)
Cheers,
Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
2009/7/7 Tarek Ziadé :
> Unless we define a "drive that contains the python installation" maybe, or
> the "Program Files" directory
>
> would that make sense from a win32 point of view ?
I can't imagine that it would be useful in practice.
> I know some people are writing to /etc to add their configuration file
> on the system,
>
> So a real-world example under linux would be:
>
> setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
>
>
> That is basically how the examples are shown at:
>
> http://docs.python.org/distutils/setupscript.html#installing-additional-files
Thanks. Yes, that makes for a good example.
> But this is already os-specific, and exists because distutils doesn't
> have a way (yet)
> to express systems locations independantly from their physical location,
> like what the RPM system does with %VARIABLES.
>
> So another way to handle this maybe, like I have added with $PREFIX
> and $EXEC_PREFIX would be to nominate a list of variables that every
> python environment has (querying modules like sys) and let the developers
> use them as root locations for some files.
>
> - sys.prefix
> - sys.exec_prefix
> - some elements returned by distutils.sysconfig.get_config_vars()
> (distutils.sysconfig queries the python Makefile amongst others)
> - ...
This adds extra complexity to the RECORD format, for little practical
benefit that I can see.
>From the POV of core distutils:
- Windows users use bdist_wininst and/or bdist_msi, and absolute
locations are a lost cause.
- Presumably, some people use bdist_rpm (I don't know if there are
other ways of creating RPMs).
- Everyone else uses setup.py install or a 3rd party tool.
- PEP 302 style loaders aren't relevant as the core only uses the
filesystem (not even zip files).
- Only 3rd party tools will consume this data.
So, we need input from developers of 3rd party tools here. Phillip has
stated the case for setuptools, from his POV having everything
relative to the "install location" which is stored elsewhere (in the
installer file) is fine. I'd like to know whether he needs
"upwards-pointing" relative paths like ../../../../xx.py, but that's a
small detail.
So - do any other potential users of the PEP 376 metadata want to speak up?
At the moment, it feels like we're designing things more or less in a vacuum.
Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
On Tue, Jul 7, 2009 at 10:33 AM, Paul Moore wrote:
> 2009/7/7 Tarek Ziadé :
>> Unless we define a "drive that contains the python installation" maybe, or
>> the "Program Files" directory
>>
>> would that make sense from a win32 point of view ?
>
> I can't imagine that it would be useful in practice.
>
>> I know some people are writing to /etc to add their configuration file
>> on the system,
>>
>> So a real-world example under linux would be:
>>
>> setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
>>
>>
>> That is basically how the examples are shown at:
>>
>> http://docs.python.org/distutils/setupscript.html#installing-additional-files
>
> Thanks. Yes, that makes for a good example.
>
>> But this is already os-specific, and exists because distutils doesn't
>> have a way (yet)
>> to express systems locations independantly from their physical location,
>> like what the RPM system does with %VARIABLES.
>>
>> So another way to handle this maybe, like I have added with $PREFIX
>> and $EXEC_PREFIX would be to nominate a list of variables that every
>> python environment has (querying modules like sys) and let the developers
>> use them as root locations for some files.
>>
>> - sys.prefix
>> - sys.exec_prefix
>> - some elements returned by distutils.sysconfig.get_config_vars()
>> (distutils.sysconfig queries the python Makefile amongst others)
>> - ...
>
> This adds extra complexity to the RECORD format, for little practical
> benefit that I can see.
>
> From the POV of core distutils:
> - Windows users use bdist_wininst and/or bdist_msi, and absolute
> locations are a lost cause.
> - Presumably, some people use bdist_rpm (I don't know if there are
> other ways of creating RPMs).
They are othe ways to generate RPMs.
There are also debian packaging scripts
> - Everyone else uses setup.py install or a 3rd party tool.
> - PEP 302 style loaders aren't relevant as the core only uses the
> filesystem (not even zip files).
> - Only 3rd party tools will consume this data.
>
> So, we need input from developers of 3rd party tools here. Phillip has
> stated the case for setuptools, from his POV having everything
> relative to the "install location" which is stored elsewhere (in the
> installer file) is fine. I'd like to know whether he needs
> "upwards-pointing" relative paths like ../../../../xx.py, but that's a
> small detail.
>
> So - do any other potential users of the PEP 376 metadata want to speak up?
>
> At the moment, it feels like we're designing things more or less in a vacuum.
I am CC'ing the people that worked with us for the versionning matters,
they can speak from a Fedora and Ubuntu POV, I am also adding Jim for
zc.buildout,
he can provide precious input.
(I am sorry if some people get the mail twice)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
On 6 Jul, 2009, at 20:38, Paul Moore wrote: - Should distribution names be case insensitive on case insensitive filesystems? For comparison, module/package names are always case sensitive even on case insensitive systems. I'd then go for case sensitive names for distributions as well, just to be consistent. But isn't the actual name in the PKG-INFO file anyway? Do you mean really case insensive filesystems like DOS' FAT, or case preserving (HFS+ on OSX, NTFS on Windows)? For the latter you can at least get the original name back using os.readdir. BTW. Actually determining if you are working with a case-sensitive fileystem requires filesystem access, os.path.normcase is hopelessly naieve in that respect. I'm reguarly dealing with NFS mounted filesystems on OSX systems, which means that parts of a path are case preserving (the HFS+ filesystem upto the mount point) and other parts are truly case sensitive (paths on the NFS mounted filesystem originating on a Linux server). Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
Paul Moore wrote:
>> I know some people are writing to /etc to add their configuration file
>> on the system,
>>
>> So a real-world example under linux would be:
>>
>> setup(..., data_files=[('/etc', ['myconf.cfg'])], ...)
>>
>>
>> That is basically how the examples are shown at:
>>
>> http://docs.python.org/distutils/setupscript.html#installing-additional-files
>
> Thanks. Yes, that makes for a good example.
>
>> But this is already os-specific, and exists because distutils doesn't
>> have a way (yet)
>> to express systems locations independantly from their physical location,
>> like what the RPM system does with %VARIABLES.
>>
>> So another way to handle this maybe, like I have added with $PREFIX
>> and $EXEC_PREFIX would be to nominate a list of variables that every
>> python environment has (querying modules like sys) and let the developers
>> use them as root locations for some files.
I think you have to differentiate between packages and applications.
Packages will usually have their own way of getting configured,
either by passing parameters via some API or pointing the package
to a configuration file. They may come with some example config
files, but should normally don't interfere with the system
configuration. I.e. putting a Python package configuration into /etc
does not really sound like a good idea.
Applications tend to ship everything needed to run the application
together with the installer and typically use a system-dependent
installer rather than a distutils based approach. These then
place config files in the usual default dirs of the system.
This is out-of-scope for PEP 376.
Then you have tools like zc.buildout which basically build
an application in some directory at "install" time. Since only
these tools know what they are doing, the whole "uninstall"
mechanism also lies in their hands. Again, PEP 376 would only
apply to the dynamic package installation part, but not to the
complete application build.
Another aspect to consider is that config files should normally
not be uninstalled automatically. The user should either be asked
whether she wants to keep the files or the uninstaller should leave
them untouched and issue a warning that certain files were not
uninstalled.
Summarizing, I think it's better not to record config files
and other user-edited files in the RECORD file.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 07 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
2009/7/7 M.-A. Lemburg : > The PEP should take the chance to define not only the > directory, but also the complete set of files in there and > their format. > > A typical setuptools dir looks like this: > > dependency_links.txt > namespace_packages.txt > not-zip-safe > PKG-INFO > requires.txt > SOURCES.txt > top_level.txt > > Ie. a complete mess of upper-case/lower-case names, names with > underscores or hyphens as word separator, files with extensions, > files without them. > > This needs some serious cleanup. > > A new dir name will allow to do this, so +1 on a new dir name. I agree the current situation is a mess. I believe that everything you mention is related to setuptools - so essentially, we have the situation: - the existing setuptools format is a mess (at least in the opinion of MAL and me :-)) - PEP 376 is an opportunity to consider cleanup - there are some strong supporters of keeping things setuptools-compatible - nobody has come forward with any other real-world use case than setuptools - consequently, those of us arguing for cleanup are talking theoretically :-( - Do you (MAL) have any real use for this data? Any non-setuptools use case, no matter how small, would really help here. I suspect practicality will beat purity here. Which would be fine, if the "practical" cases weren't just setuptools. I understood that there was a lot of interest in a "distutils cleanup" from the packaging community. And yet so far in this discussion, the main participants have seemed to be (apologies to anyone if I've misunderstood their position): - Tarek, trying to get the proposal he thrashed out in the distutils SIG agreed - Me, advocating Windows issues and PEP 302 integration (to cover eggs and general flexibility) - Phillip (and occasional others), representing setuptools POV - Interested python-dev participants Nobody representing any other 3rd party packaging solution than setuptools. Much as I'd like to, I can't really argue the case for breaking setuptools compatibility without practical reasons. And if we're not going to do that, PEP 376 reduces to a further stage of the incremental move of setuptools into distutils core (by removing the partial solution of a .egg-info file, and replacing it with a full setuptools .egg-info directory, plus a few introspection APIs as a sweetener). 2009/7/7 Ronald Oussoren : > But why break existing code without having any other benifits? If I read > the discussion correctly the name would be changed without any changes to > the contents of the metadata directory. I would be more inclined to be in > favour if the name change had a sound technical reason, such as a change of > the contents of the directory which would make setuptools "egg-info" > directories incompatible with the PEP376 ones. See MAL's comments above, and my response. If (and only if!) his proposal is accepted, then a name change starts to be worth discussing further. As things stand at the moment, the structure appears to be setuptools-compatibile (other than the new RECORD file, which Phillip has committed to adding) so a name change isn't worth it. I can't comment myself on setuptools compatibility, so I'm assuming here that Phillip will speak up if the proposed format is *not* compatible... Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
Paul Moore wrote: > 2009/7/7 M.-A. Lemburg : >> The PEP should take the chance to define not only the >> directory, but also the complete set of files in there and >> their format. >> >> A typical setuptools dir looks like this: >> >> dependency_links.txt >> namespace_packages.txt >> not-zip-safe >> PKG-INFO >> requires.txt >> SOURCES.txt >> top_level.txt >> >> Ie. a complete mess of upper-case/lower-case names, names with >> underscores or hyphens as word separator, files with extensions, >> files without them. >> >> This needs some serious cleanup. >> >> A new dir name will allow to do this, so +1 on a new dir name. > > I agree the current situation is a mess. I believe that everything you > mention is related to setuptools - so essentially, we have the > situation: > > - the existing setuptools format is a mess (at least in the opinion of > MAL and me :-)) > - PEP 376 is an opportunity to consider cleanup > - there are some strong supporters of keeping things setuptools-compatible > - nobody has come forward with any other real-world use case than setuptools > - consequently, those of us arguing for cleanup are talking theoretically :-( > - Do you (MAL) have any real use for this data? Any non-setuptools use > case, no matter how small, would really help here. No, we currently don't have a package installer that would implement what setuptools does on the user side, but without all the black magic stuff. What we do have is a somewhat different approach to packaging binary packages: we call them pre-built archives. The idea is that the developer runs a complete build command on the target platform, the bdist_prebuilt command then packages up everything (including the current state of distutils) and the user then runs the usual python setup.py install on her machine to complete the setup. The major advantage here is that the user actually has full control over where things are installed and how. So whatever distutils implements as part of the install command, this format will also support. We also provide an uninstall command, that basically runs an installation in reverse. Something else we've done recently is write a bdist_egg command that creates .egg files without relying on setuptools. It's fairly easy to do and if there's interest, I can add that to core distutils. Changing the layout of the EGG-INFO dir embedded in those .egg files is pretty easy to do, so I don't really see much of a problem with changing it or renaming the dir. > I suspect practicality will beat purity here. Which would be fine, if > the "practical" cases weren't just setuptools. > > I understood that there was a lot of interest in a "distutils cleanup" > from the packaging community. And yet so far in this discussion, the > main participants have seemed to be (apologies to anyone if I've > misunderstood their position): > > - Tarek, trying to get the proposal he thrashed out in the distutils SIG > agreed > - Me, advocating Windows issues and PEP 302 integration (to cover eggs > and general flexibility) > - Phillip (and occasional others), representing setuptools POV > - Interested python-dev participants > > Nobody representing any other 3rd party packaging solution than setuptools. Well I've added another one above, the pre-built approach :-) Writing an uninstall command really isn't all that hard, provided you stick with the standard distutils "python setup.py install" dance. The whole packaging approach only complicates things, IMHO. > Much as I'd like to, I can't really argue the case for breaking > setuptools compatibility without practical reasons. And if we're not > going to do that, PEP 376 reduces to a further stage of the > incremental move of setuptools into distutils core (by removing the > partial solution of a .egg-info file, and replacing it with a full > setuptools .egg-info directory, plus a few introspection APIs as a > sweetener). Uhm, we are talking about a Python standard here and since there is no prior implementation in Python stdlib, we're not breaking anything and are free to design whatever we like. Of course, it does make a lot of sense to build upon things that have been used in the past, so looking at setuptools is certainly a useful strategy. However, let's learn from their mistakes and take the change to clean up things a bit. There are good reasons to do so: * the naming scheme should be concise * the meta-data directory should get a name that doesn't imply any specific distribution form... Calling the directory .egg-info is natural if you're only dealing with eggs. It is not when running standard "python setup.py install" or having a mixed setup using different packaging mechanisms. > 2009/7/7 Ronald Oussoren : >> But why break existing code without having any other benifits? If I read >> the discussion correctly the name would be changed without any changes to >> the contents of the metadata directory. I would be more inclined to be in >> favour if the name ch
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
On Tue, Jul 7, 2009 at 11:28 AM, M.-A. Lemburg wrote: > > Writing an uninstall command really isn't all that hard, provided > you stick with the standard distutils "python setup.py install" > dance. The whole packaging approach only complicates things, IMHO. You can't expect people to keep the distribution they used to install in a corner of their hard drive, to make sure they will be able to uninstall it (or to ask them to download it again) That's all about the RECORD files and the asymetric uninstall script described in PEP 376. having an uninstall command on the top of the uninstall script is a nice shortcut though. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
2009/7/7 M.-A. Lemburg : > I think you have to differentiate between packages and applications. Agreed. I believe that only packages should be considered here. Applications are the focus of tools like py2exe on Windows, and (AIUI) things like workingenv. These tools should (will) have their own approaches. The only cases I know where there is reason for a package to store paths outside the package directory are: - executable scripts, which go in sys.prefix/Scripts on Windows, and ??? on Unix/MAC OS - supporting files (MoinMoin puts its HTML documents etc in sys.prefix/share on Windows, cx_Oracle puts its documentation in sys.prefix/cx_Oracle-doc) Executable files could probably be superseded by using "python -m", but compatibility and users' preference for having a "real script" probably means they aren't going away in the near future. Support files are getting put in the package directory more often these days, but stuff that needs to be found by non-Python tools is arguably still better in a more discoverable location. For Windows, having a few distinguished locations under the installation root (scripts, share, doc) would probably do. For Unix and Mac OS, I have no opinion (but I suspect that absolute paths like /usr/local/bin might be the norm there). [...] > Summarizing, I think it's better not to record config files > and other user-edited files in the RECORD file. The RECORD file should contain precisely those files that are created as part of the install. That's ultimately the point of the file (for ownership queries and uninstallation). Hmm, on the other hand, if foo.py is in the RECORD file, the uninstaller should uninstall foo.pyc and foo.pyo as well. And a query as to whether the distribution owns foo.pyc should return True. How will this be handled? Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
2009/7/7 M.-A. Lemburg : > Well I've added another one above, the pre-built approach :-) Thanks! That's a lot of help. Are there any public examples, or is your format only used internally? Would you expect to use any of the new pkgutil APIs - for example, to check if a distribution is installed, and/or the installed version? Or to check you're not overwriting a file owned by another distribution? Or would you get any value from storing your own format-specific metadata files in the egg-info directory? If all you care about is that setup.py install continues to work, my suspicion is that PEP 376 won't have much to offer you, whatever happens. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
Paul Moore wrote:
> 2009/7/6 Nick Coghlan :
> - There are *no* guaranteed absolute locations on Windows, so any such
> oddly-located file would require user interaction to work. Certainly
> bdist_wininst and bdist_msi don't do that.
> - My experiments indicate that bdist_{wininst,msi} are broken with
> respect to absolute paths anyway: they do a --root install to a
> temporary directory (and the absolute paths don't end up in there) and
> then package up that temporary directory.
>
> I still want to see a real life example that demonstrates that there
> is a genuine issue here. We're spending a lot of energy and complexity
> trying to design a solution to a problem that actually doesn't appear
> to exist in practice...
>
> (To be honest, I'd be fairly confident in saying that absolute paths
> can be ignored on Windows, subject to some corner cases that I haven't
> thought through yet. My worry is that I don't know what Unix and Mac
> users might do, so I can't just wish away the issue because it can't
> arise on Windows. Can a Unix/Mac user offer a real-world example on
> their own system?)
I thought installing pywin32 based COM objects still involved messing
with the Windows directory, but MS may have improved that in more recent
OS versions. It's been years since I played with win32com objects, and
even then it was just idle experimentation that didn't get very far so I
could easily be misremembering.
For *nix, the obvious use case is installing scripts somewhere like
/usr/bin or /usr/local/bin.
One option is to punt on this whole issue and say if people want to
install stuff outside the Python module heirarchy they should create
their own OS-specific package to manage it (i.e. leave the non-relative
paths to be managed by APT or a Windows installer or whatever).
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
Paul Moore writes: > The only cases I know where there is reason for a package to store > paths outside the package directory are: I think the *only* files that actually belong in the package directory are the Python modules inside that package. Other files need to be easily, and automatically, separable for purposes of installation. > - executable scripts, which go in sys.prefix/Scripts on Windows os.path.join(sys.prefix, 'Scripts') > and ??? on Unix/MAC OS Depending on whether the developer designates the programs for sysadmin-only use or not: os.path.join(sys.prefix, 'bin') os.path.join(sys.prefix, 'sbin') > - supporting files (MoinMoin puts its HTML documents etc in > sys.prefix/share on Windows, cx_Oracle puts its documentation in > sys.prefix/cx_Oracle-doc) This category, it seems to me, needs to be expanded with metadata that allows “purpose”-based tagging, so that platform-specific standards can be applied using those purposes to determine the correct location for these non-Python-module files. > Support files are getting put in the package directory more often > these days Only, IMO, because there's no way of flagging it as anything but arbitrary “data”. Examples of purpose-based classifications that need to be distinctly declarable: executable program, importable module source, platform-independent compiled module, platform-dependent compiled module, documentation, run-time variable data, static data, configuration, and so on. All of these (and others I've forgotten) should be possible for the developer to declare in distribution metadata, and the installer can then use those declarations to make the files go to platform-specific locations, not the Python package directories. > For Windows, having a few distinguished locations under the > installation root (scripts, share, doc) would probably do. For Unix > and Mac OS, I have no opinion (but I suspect that absolute paths like > /usr/local/bin might be the norm there). The lines are drawn in different places on each platform; we don't want to have the union of all these different platform-specific locations in the standard, and likewise we don't want to leave any of them with second-class support. I think it's not the developer's burden to decide *where* such files go; rather, they should be declaring only the *purpose* of these files in the distribution metadata, and it's up to the site-specific installer (possibly as configured by the installing user) to decide the location of each file by its declared purpose. -- \ “I can picture in my mind a world without war, a world without | `\ hate. And I can picture us attacking that world, because they'd | _o__) never expect it.” —Jack Handey | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
Paul Moore writes: > I agree the current situation is a mess. I believe that everything you > mention is related to setuptools - so essentially, we have the > situation: > > - the existing setuptools format is a mess (at least in the opinion of > MAL and me :-)) No argument from me on this point. > - PEP 376 is an opportunity to consider cleanup > - there are some strong supporters of keeping things > setuptools-compatible Your implication seems to be that these two are incompatible. It should be noted that it's possible to clean up, by having a separate (e.g. ‘.pydist’) directory as the new standard, with “cleaned up” standard content, and continue backward compatibility in the actual tools while deprecating the old ‘.egg-info’ format for some time until finally removing that support. > Much as I'd like to, I can't really argue the case for breaking > setuptools compatibility without practical reasons. Agreed. I think we should be making it clear that ‘.egg-info’ is not going to evolve any further, and that it will eventually go away; but not remove support for it until there's a clearly established replacement. -- \ “I got up the other day, and everything in my apartment has | `\ been stolen and replaced with an exact replica.” —Steven Wright | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
2009/7/7 Ben Finney : [... lots of interesting stuff deleted ...] > I think it's not the developer's burden to decide *where* such files go; > rather, they should be declaring only the *purpose* of these files in > the distribution metadata, and it's up to the site-specific installer > (possibly as configured by the installing user) to decide the location > of each file by its declared purpose. That's a whole different PEP, though. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
2009/7/7 Ben Finney : >> - PEP 376 is an opportunity to consider cleanup >> - there are some strong supporters of keeping things >> setuptools-compatible > > Your implication seems to be that these two are incompatible. It should > be noted that it's possible to clean up, by having a separate (e.g. > ‘.pydist’) directory as the new standard, with “cleaned up” standard > content, and continue backward compatibility in the actual tools while > deprecating the old ‘.egg-info’ format for some time until finally > removing that support. Phillip argued strongly against this. I'm not going to repeat his arguments - they seemed to make sense to me at the time, but I haven't internalised them well enough that I'd be willing to try to repeat them here. The crux of all this seems to be setuptools' backwards compatibility issues, As someone who has a very strong dislike of setuptools (the implementation, not the ideas), I'm trying very, very hard to leave it to someone else to say "stuff setuptools, this is a core distutils proposal, setuptools can keep up or die" :-) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote: 2009/7/7 Ben Finney : [... lots of interesting stuff deleted ...] I think it's not the developer's burden to decide *where* such files go; rather, they should be declaring only the *purpose* of these files in the distribution metadata, and it's up to the site-specific installer (possibly as configured by the installing user) to decide the location of each file by its declared purpose. That's a whole different PEP, though. Which one? It seems to me that supporting this is implicit in the language summit goals of (1) having distutils be better support infrastructure for system packaging utilities and (2) needing a way to deal with resource files "that might be installed in a specific place on the target system by the system packager". I'll grant that I'm reading between the lines, it isn't an explicitly stated goal. But it was the direction my mind went when I read Tarek's notes, given that the first stated goal is "standardize more metadata". But I'm not one of the people involved in system packaging tools, so I'll leave it to them to say how useful/important this is. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
On Tue, Jul 7, 2009 at 2:52 PM, R. David Murray wrote: > On Tue, 7 Jul 2009 at 13:05, Paul Moore wrote: >> >> 2009/7/7 Ben Finney : >> [... lots of interesting stuff deleted ...] >>> >>> I think it's not the developer's burden to decide *where* such files go; >>> rather, they should be declaring only the *purpose* of these files in >>> the distribution metadata, and it's up to the site-specific installer >>> (possibly as configured by the installing user) to decide the location >>> of each file by its declared purpose. >> >> That's a whole different PEP, though. > > Which one? It seems to me that supporting this is implicit in > the language summit goals of (1) having distutils be better support > infrastructure for system packaging utilities and (2) needing a way to > deal with resource files "that might be installed in a specific place on > the target system by the system packager". I'll grant that I'm reading > between the lines, it isn't an explicitly stated goal. But it was the > direction my mind went when I read Tarek's notes, given that the first > stated goal is "standardize more metadata". Yes but the topic is so wide that it has to be cut in several PEP, and things have to be done gradually So far: - PEP 376 : standard for the metadata format and location + query APIs - PEP 345 : standard for the metadata *content* - work in progress too (there's a branch with new fields waiting) - PEP 386 : standard for version comparisons topics that are not yet in PEP are grouped on the wiki page (under "current work") with notes : http://wiki.python.org/moin/Distutils When I started to work on this I didn't realize the gigantic amount of work and coordination it requires, and I do understand now the current state. At first I was trying to coordinate interested people to work on each topic mentioned there in parallel. (like we did a bit after the summit) But at the end, it seems that having everyone interested in packaging matters focusing on the less number of possible topics pays more. PEP 376 is just a piece of the puzzle but I am confident it will speed up other tasks since it raises our common ground knowledge. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
Brett Cannon wrote: > On Mon, Jul 6, 2009 at 07:51, M.-A. Lemburg wrote: > >> Dirkjan Ochtman wrote: >>> In response to some rumblings on python-committers and just to request >>> more feedback, a progress report. I know it's long, I've tried to put >>> to keep it concise and chunked, though. >> Two things: >> >> * We need some form of documentation of how committers are expected >> to work with the hg repo. (This is also missing for the Subversion >> repo, which due to the 3.x branch has gotten somewhat unclear - at >> least for me) >> > > I am planning to get a version of the dev FAQ written up that covers most of > what it already does now for svn. > > >> It is currently not clear where to check in patches, whether and >> where to backport or forward-patch, which branches to consider >> closed, etc. >> >> E.g. if I check in something in trunk/ (Python 2.7), do I have to >> forward patch this change to the 3.0 branch (guess not), the py3k/ >> branch (Python 3.1), or will someone else take care of this, so that >> it's better not to interfere by doing it myself ? >> > > This question is partially answered by > http://www.python.org/dev/faq/#how-do-i-merge-between-branches, but I agree > that we should have either this spelled out in the FAQ or a > committer-specific doc at www.python.org/dev/ that makes this all very > obvious. The merge process itself is more or less clear. What I'm missing is the agreed upon strategy for applying the patches to the various branches. I've seen a few discussions about this, but no final statement of what strategy to follow and whether hg makes this easier (AFAIR, that was the main argument for switching to hg). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 07 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
Dirkjan Ochtman wrote:
> On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
>> Is there a standard notation for hg revisions that roundup could
>> detect and turn into links (much like it does for svn) ?
>
> [a-f0-9]{12} should mostly do.
Hmm, no prefix or suffix ?
So we'll always have to write "see deadbeefdeadbeefff for details"
or "Reverting f00fl33df00fl33d00 after problems on Pentium CPUs" ?!
Cheers,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 07 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
On Tue, Jul 7, 2009 at 15:32, M.-A. Lemburg wrote: > Hmm, no prefix or suffix ? No, not really. hg often shows revision integers as well, but as they aren't globally consistent, they're of little value in communicating changeset pointers. > So we'll always have to write "see deadbeefdeadbeefff for details" > or "Reverting f00fl33df00fl33d00 after problems on Pentium CPUs" ?! Yes. And it's really not that bad. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote: The merge process itself is more or less clear. What I'm missing is the agreed upon strategy for applying the patches to the various branches. I've seen a few discussions about this, but no final statement of what strategy to follow and whether hg makes this easier (AFAIR, that was the main argument for switching to hg). I think the main reason for switching was that it would make it easier for non-core-committers to maintain branches and submit patches (as changesets core committers can pull). I don't think it was ever clear that the merge workflow would in fact get easier, except insofar as hg's merge support is better than SVN's (at least, I believe people have said that last is true). There is _hope_ that it will be easier, but I think it remains to be proven/worked out. And I believe there is no tool like svnmerge for tracking changesets to be merged, which could be an issue that needs a resolution. IIUC, the discussion about named versus cloned branches is part of figuring out the workflow --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
In Python3 PySys_SetArgv takes (wchar_t **) for the argv, I looked into converting a (char **) into a (wchar_t **) and while its possible its lengthy enough not to be trivial, see python.c:18 - char2wcharm(), its 102 lines with ifdef's and goto's, not including the loop lower down that loops over the argv. Looking further python has a very similar function for ./PC/bdist_wininst/install.c, for do_run_installscript - widen_string(). Since many C applications take argv as a (char **) it seems reasonable for python to keep a function for the C api that accepts a (char **) argument for argv. otherwise each C applications that embeds python will need to write their own conversion function. also noticed Demo/embed/demo.c is out of date, giving (char **) to PySys_SetArgv(). -- - Campbell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "Absolute" paths in PEP 376 RECORD files
Just an idea... suppose that instead of using "real" absolute paths in the RECORD file for non-local files (scripts, data, etc) we changed the format to include a "prefix" field, containing something like LIBDIR, SHARE, SCRIPTS, etc., ala bdist_wininst internals? Also, we could include a separate (optional) PREFIXES file defining what those locations translated to at install time. Dumb bdists would still have their build paths there (or delete the file before packaging, or use real paths instead of the --root prefixed versions). Upside: relocation can be detected and handled, RECORD remains cross-platform, and bdists are ok. Downside: more complex API required to read/manipulate paths and delete files, since you need to be able to check that you have the right prefixes, and may have to ask the user for a prefix you don't recognize, if the default in PREFIXES doesn't match. Thoughts? (Also, as a special case, any file that's actually installed to LIBDIR or a subdirectory thereof (even if it's technically a "data" file or script), will probably need to be designated under LIBDIR prefix to prevent runtime breakage in the event any system package maintainers are tempted to use RECORD files as a way of forcing a HFS conformance. These are installation prefixes, *not* content types.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote: When I started to work on this I didn't realize the gigantic amount of work and coordination it requires No one expects the package inquisition. ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
Paul Moore wrote: > 2009/7/7 Ben Finney : >>> - PEP 376 is an opportunity to consider cleanup >>> - there are some strong supporters of keeping things >>> setuptools-compatible >> Your implication seems to be that these two are incompatible. It should >> be noted that it's possible to clean up, by having a separate (e.g. >> ‘.pydist’) directory as the new standard, with “cleaned up” standard >> content, and continue backward compatibility in the actual tools while >> deprecating the old ‘.egg-info’ format for some time until finally >> removing that support. > > Phillip argued strongly against this. I'm not going to repeat his > arguments - they seemed to make sense to me at the time, but I haven't > internalised them well enough that I'd be willing to try to repeat > them here. > > The crux of all this seems to be setuptools' backwards compatibility > issues, As someone who has a very strong dislike of setuptools (the > implementation, not the ideas), I'm trying very, very hard to leave it > to someone else to say "stuff setuptools, this is a core distutils > proposal, setuptools can keep up or die" :-) Actually, the approach Ben suggests is the same as the one I suggested for dealing with the backwards compatibility problem (i.e. distutils would install both the existing .egg-info for detection by existing packaging tools, while putting the new stuff in a .pydist directory). The argument against *that* approach to backwards compatibility is the accumulation of cruft in site-packages (and other module installation directories) since even a simple installation of a single module or small package would now be generating at least *three* entries in the relevant directory (.egg-info, .pydist and the module or package itself). Retaining the .egg-info naming provides detection of installed distributions by old packaging systems with a minimum of cruft on the end user's system. The only possible advantage changing the extension name might give us is making it fractionally easier to clean up the contents of the .egg-info directory, but I don't think it will actually make that much difference (i.e. it really shouldn't be that hard to keep the new PEP 376 based filenames all UPPERCASE and distinct from any filenames currently stored in the directory by setuptools or other packaging utilities) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
2009/7/7 Paul Moore : > > The RECORD file should contain precisely those files that are created > as part of the install. That's ultimately the point of the file (for > ownership queries and uninstallation). > > Hmm, on the other hand, if foo.py is in the RECORD file, the > uninstaller should uninstall foo.pyc and foo.pyo as well. And a query > as to whether the distribution owns foo.pyc should return True. How > will this be handled? It's planned to list them as well in RECORD, since install calls a sub command that build thems (install_lib), So the same rules apply than the .py ones. But there's a special case : if the --no-compile or the --no-optimize option is used, then the pyc|pyo files are not added. Which means they will be created afterwards when the module is used on the target system. So the pyc|pyo files could be removed when they are present besides the py file that is being removed. Although, it will still be required to write them in the RECORD file by the install command when the --no-compile or the --no-optimize options are *not* used. So they are properly detected and removed when the py files are not distributed in binary distributions, but just pyc files. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
2009/7/7 Nick Coghlan :
> For *nix, the obvious use case is installing scripts somewhere like
> /usr/bin or /usr/local/bin.
Using distutils' scripts option, they will end up in : sys.exec_path/bin
Another use case I've found in a distro I've installed this afternoon :
setup(..., data_files=[('/usr/share/man/man1/', ['SOMEFILE'])], ...)
That's not the most elegant way to add a man page, but for someone
who doesn't bather with APT or whatever, it works to build a binary
distribution.
>
> One option is to punt on this whole issue and say if people want to
> install stuff outside the Python module heirarchy they should create
> their own OS-specific package to manage it (i.e. leave the non-relative
> paths to be managed by APT or a Windows installer or whatever).
If so, what do we do with the "data_files" option in distutils ?
If it's used with absolute paths, files can be installed anywhere on
the system, and we want to track them.
Even if we don't uninstall them automatically, they should be tracked
so a third-party
uninstaller can deal with them properly.
Or do we change this distutils feature and state that the directories
used in "data_files"
will always be relative to sys.prefix ?
That would bring us back to three cases in the RECORD:
- files located under sys.prefix, but not located under site-packages
- files located under sys.exec_prefix, but not located under site-packages
- files located under site-packages
Where "site-packages" is the directory that contains .egg-info
directory of the distribution
(that's basically the current PEP state, beside the absolute paths
case we would need to remove)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 376 - RECORD format proposal
Hello,
Let's state that we don't allow absolute paths in RECORD file and see
what we can
do with other paths.
First as a reminder, here's the full list of directories used by
Distutils at installation time.
The "install" command uses five options to decide where to install the files.
The default values are:
Unix:
install_purelib: sys.prefix/lib/python2.6/site-packages
install_platlib: sys.exec_prefix/lib/python2.6/site-packages
install_headers: sys.prefix/include/python2.6/docutils
install_scripts: sys.prefix/bin
install_data : sys.prefix
Unix, using the home option, instead of sys.prefix/sys.exec_prefix:
install_purelib: home/lib/python
install_platlib: home/lib/python
install_headers: home/include/python/$dist_name
install_scripts: home/bin
install_data : home
Windows:
install_purelib: sys.prefix/Lib/site-packages
install_platlib: sys.prefix/Lib/site-packages
install_headers: sys.prefix/Include/python2.6/docutils
install_scripts: sys.prefix/bin
install_data : sys.prefix
There are also some old scheme for os.name in ('mac', 'os2') I need to
cleanup asap in there,
but I won't mention them.
Last, there's now the new per user site-package that adds more
potential locations. e.g. replaces
sys.prefix and sys.exec_prefix with two user directories.
So they are all located under two root locations at the max.
But since these are all overridable options (in pydistutils.cfg,
distutils.cfg, etc) files can be located under *five* different
roots.
So my proposal is to write those five roots in a header line in the
RECORD file, and use them as prefixes
to locate the files that are not under the directory where the
egg-info dir is located (which will be kept : relative paths)
purelib,xxx,headers,xxx,scripts,xxx,install_data,xxx
...
$purelib/some/file
...
How does that sounds ?
Tarek.
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
M.-A. Lemburg wrote:
> Dirkjan Ochtman wrote:
>> On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
>>> Is there a standard notation for hg revisions that roundup could
>>> detect and turn into links (much like it does for svn) ?
>> [a-f0-9]{12} should mostly do.
>
> Hmm, no prefix or suffix ?
>
> So we'll always have to write "see deadbeefdeadbeefff for details"
> or "Reverting f00fl33df00fl33d00 after problems on Pentium CPUs" ?!
No, rather "see deadbeefdead for details" and
"Reverting f00fl33df00fl33d00 after problems on Pentium CPUs".
In practice, rather 30ba63d28b1b or 12fb3b32d75d (from html5lib,
fwiw).
Dirkjan meant "[a-f0-9]{12}" literally.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote: > At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote: >> >> When I started to work on this I didn't realize the gigantic amount of >> work and coordination it requires > > No one expects the package inquisition. ;-) > > Sorry, i've looked in the english dictionary but I don't get this one. what do you mean ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
>> Hmm, no prefix or suffix ? > > No, not really. hg often shows revision integers as well, but as they > aren't globally consistent, they're of little value in communicating > changeset pointers. I think MAL wasn't asking for a "1354:" prefix, but for a, say, "r" or "R" prefix, or perhaps "V" or "merc:". I think you are proposing that there is no prefix because the chance for a misidentification of some word as a hg revision number is small, as it has to be exactly 12 hex digits. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
On Tue, 7 Jul 2009 at 23:30, Tarek Ziad? wrote: On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote: At 03:23 PM 7/7/2009 +0200, Tarek Ziad? wrote: When I started to work on this I didn't realize the gigantic amount of work and coordination it requires No one expects the package inquisition. ?;-) Sorry, i've looked in the english dictionary but I don't get this one. what do you mean ? See the recent thread on python-committers about mandatory Monty Python cultural education for committers :) See also http://www.youtube.com/watch?v=gldlyTjXk9A --David___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
Tarek Ziadé wrote: > On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote: >> At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote: >>> When I started to work on this I didn't realize the gigantic amount of >>> work and coordination it requires >> No one expects the package inquisition. ;-) >> >> > > Sorry, i've looked in the english dictionary but I don't get this one. > what do you mean ? It's a Monty Python reference: http://en.wikipedia.org/wiki/The_Spanish_Inquisition_(Monty_Python) http://www.youtube.com/watch?v=gldlyTjXk9A Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
>> I've seen a few discussions about this, but no final statement >> of what strategy to follow and whether hg makes this easier (AFAIR, >> that was the main argument for switching to hg). > > I think the main reason for switching was that it would make it easier > for non-core-committers to maintain branches and submit patches (as > changesets core committers can pull). Indeed, it's all in PEP 374: - motivation 1: give direct tool support to non-committers - motivation 2: allow disconnected (off-line) access to the repository - motivation 3: allow revisions of a patch - motivation 4: allow tracking the mainline while working on a patch - motivation 5: avoid using arcane third-party tools for merge tracking So merge tracking was not the main argument, but the fifth. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
Martin v. Löwis wrote: > I think you are proposing that there is no prefix because the chance > for a misidentification of some word as a hg revision number is small, > as it has to be exactly 12 hex digits. So triggering it accidentally would require a 12 letter word or object name that used only the letter a-f? Agreed that seems very unlikely. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
> Since many C applications take argv as a (char **) it seems reasonable > for python to keep a function for the C api that accepts a (char **) > argument for argv. I'm not quite sure what you are suggesting: either that there is a function in the C API that accepts a (char**), or that PySys_SetArgv be that function. The latter alternative is out of question, as it breaks the Windows port of Python - there is simply no way of representing argv with char** in a meaningful way. It also breaks backwards compatibility. As for creating another function: please provide a patch to bugs.python.org. I believe this patch is *very* difficult to implement, unless the function can accept some severe limitations. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
Sorry... -- Forwarded message -- From: Lisandro Dalcin Date: Tue, Jul 7, 2009 at 7:16 PM Subject: Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ? To: "Martin v. Löwis" On Tue, Jul 7, 2009 at 6:46 PM, "Martin v. Löwis" wrote: >> Since many C applications take argv as a (char **) it seems reasonable >> for python to keep a function for the C api that accepts a (char **) >> argument for argv. > I've run in the same issue, and basically had to copy&paste from Python sources... > > I'm not quite sure what you are suggesting: either that there is a > function in the C API that accepts a (char**), or that PySys_SetArgv > be that function. > > The latter alternative is out of question, as it breaks the Windows > port of Python - there is simply no way of representing argv with > char** in a meaningful way. It also breaks backwards compatibility. > Indeed... > As for creating another function: please provide a patch to > bugs.python.org. I believe this patch is *very* difficult to > implement, unless the function can accept some severe limitations. > What about the Python lib exposing a public PyOS_char2wchar() ? No idea how to write a Windows implementation, though.. -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
Tarek Ziadé writes: > On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote: > > No one expects the package inquisition. ;-) > Sorry, i've looked in the english dictionary but I don't get this one. I think that far more important than PEP 385 conversion of Roundup and other utilities to recognize Mercurial revision identifiers is a filter for Python channels that recognizes Monty Python references and automatically inserts YouTube video URLs for this essential background. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
R. David Murray writes: > On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote: > > I've seen a few discussions about this, but no final statement > > of what strategy to follow and whether hg makes this easier (AFAIR, > > that was the main argument for switching to hg). Yes, yes, yes, and no. In reverse order, no: the main argument for switching to hg is that it makes private branching easier. Yes: hg will make public branching easier, too, but that can't be proved until the workflow adjustments get worked out. For that reason, it is essential that the current workflow be supportable essentially without change, and it is. With respect to "how", I'm not a Mercurial geek, but I have been working with Mercurial queues a bit recently in another area, and I think they have some promise for helping organize the workflow. (Although by themselves they're clearly not sufficient, since they're oriented to a single branch.) Yes: there has been no final statement of what strategy to follow because opinions are extremely varied, even as to what is feasible with Mercurial. For example, Dirkjan and Georg want a workflow that makes moving patches among the public branches worry-free Mercurial merges. I believe that means (to the extent it is implemented) essentially gutting the current strategy of cutting maintenance branches and simply lagging the maintenance branches relative to the dev branches, and that it's infeasible for py3k vs. py2. I can't substantiate that; maybe the patch flow would support what they want, I'm not that familiar with how much patches currently morph across branches. And yes: there are a few inconclusive discussions. That's why PEP 374 was written consciously with the intent of postponing the hard issues of workflow across the public branches in favor of picking off the low hanging fruit of private branching and disconnected version control. > I think the main reason for switching was that it would make it easier > for non-core-committers to maintain branches and submit patches (as > changesets core committers can pull). Patches or "bundles" aka merge directives. "Pulling" submissions is probably not going to happen; that's a practice that is common with highly distributed workflows, but Python has a fairly centralized workflow. > but I think it remains to be proven/worked out. And I believe there is > no tool like svnmerge for tracking changesets to be merged, which could > be an issue that needs a resolution. I think that Mercurial queues or some related extension can be adapted to this, but I can't say for sure (after all, I was the git person on the PEP 374 team :-). > IIUC, the discussion about named versus cloned branches is part of > figuring out the workflow Peripherally. But actually it's not really relevant to workflow. Anything that can be done with named branches can be done with cloned branches, possibly requiring substantially more space. That discussion really is about whether anything is *lost* by using named branches. I worry that something is lost, but the discussion so far has been inconclusive. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
The reason I was a big vague is that I'm not really bothered HOW its done, I'd just like there to be some way to use PySys_SetArgv with a (char **) Definitely not suggesting that PySys_SetArgv be reverted to the way it worked in py2.x, if there was 2 versions of PySys_SetArgv that would be acceptable to me. PySys_SetArgvASCII() maybe? Alternately a function to convert the char **argv to wchar_t **argv could be ok too. PyOS_char2wchar would be useful though it still means you need to manually copy the argv, convert and free it. On Tue, Jul 7, 2009 at 3:18 PM, Lisandro Dalcin wrote: > Sorry... > > -- Forwarded message -- > From: Lisandro Dalcin > Date: Tue, Jul 7, 2009 at 7:16 PM > Subject: Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ? > To: "Martin v. Löwis" > > > On Tue, Jul 7, 2009 at 6:46 PM, "Martin v. Löwis" wrote: >>> Since many C applications take argv as a (char **) it seems reasonable >>> for python to keep a function for the C api that accepts a (char **) >>> argument for argv. >> > > I've run in the same issue, and basically had to copy&paste from > Python sources... > >> >> I'm not quite sure what you are suggesting: either that there is a >> function in the C API that accepts a (char**), or that PySys_SetArgv >> be that function. >> >> The latter alternative is out of question, as it breaks the Windows >> port of Python - there is simply no way of representing argv with >> char** in a meaningful way. It also breaks backwards compatibility. >> > > Indeed... > >> As for creating another function: please provide a patch to >> bugs.python.org. I believe this patch is *very* difficult to >> implement, unless the function can accept some severe limitations. >> > > What about the Python lib exposing a public PyOS_char2wchar() ? > > No idea how to write a Windows implementation, though.. > > > -- > Lisandro Dalcín > --- > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > > > > -- > Lisandro Dalcín > --- > Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) > Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) > Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) > PTLC - Güemes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 > -- - Campbell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote: On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote: > At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote: >> >> When I started to work on this I didn't realize the gigantic amount of >> work and coordination it requires > > No one expects the package inquisition. ;-) > > Sorry, i've looked in the english dictionary but I don't get this one. what do you mean ? It's a Monty Python reference, i.e. "no one expects the Spanish Inquisition". In the Spanish Inquisition sketch, a character is asked several questions he can't answer, and then complains that he wasn't expecting some kind of Spanish inquisition, at which point three scarlet-robed cardinals burst into the room and exclaim, "NO ONE expects the Spanish Inquisition!" So I punned on that in order to imply that nobody who takes on the job of packaging expects to be asked the kind of detailed, unanswerable questions that come with the territory of packaging, or to be subjected to torture by third parties merely for trying to do something useful. And, by further implication, I was thus expressing camaraderie with you on your initiation into the wonderful world of trying to satisfy everyone in Pythonland, and our shared experience in the area of "if I'd really known what I was getting into, I probably wouldn't have". ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Suggested PySys_SetArgv use with a (char **) argv ?
> The reason I was a big vague is that I'm not really bothered HOW its
> done, I'd just like there to be some way to use PySys_SetArgv with a
> (char **)
Ok, that's easy:
void PySys_SetArgvChar(int argc, char** argv)
{
PySys_SetArgv(0, NULL);
}
So you don't bother *how* it's done as long as you can pass char**
in some way.
> Alternately a function to convert the char **argv to wchar_t **argv
> could be ok too.
Convert in what manner? What is the encoding of your char**?
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376 - Open questions
On Wed, Jul 8, 2009 at 7:09 AM, P.J. Eby wrote: > At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote: >> >> On Tue, Jul 7, 2009 at 10:31 PM, P.J. Eby wrote: >> > At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote: >> >> >> >> When I started to work on this I didn't realize the gigantic amount of >> >> work and coordination it requires >> > >> > No one expects the package inquisition. ;-) >> > >> > >> >> Sorry, i've looked in the english dictionary but I don't get this one. >> what do you mean ? > > It's a Monty Python reference, i.e. "no one expects the Spanish > Inquisition". > > In the Spanish Inquisition sketch, a character is asked several questions he > can't answer, and then complains that he wasn't expecting some kind of > Spanish inquisition, at which point three scarlet-robed cardinals burst into > the room and exclaim, "NO ONE expects the Spanish Inquisition!" > > So I punned on that in order to imply that nobody who takes on the job of > packaging expects to be asked the kind of detailed, unanswerable questions > that come with the territory of packaging, or to be subjected to torture by > third parties merely for trying to do something useful. > > And, by further implication, I was thus expressing camaraderie with you on > your initiation into the wonderful world of trying to satisfy everyone in > Pythonland, and our shared experience in the area of "if I'd really known > what I was getting into, I probably wouldn't have". ;-) Hehe very nice, thanks for the explanation :) (thanks to the others too) > > -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
