Re: [Python-Dev] PEP 376

[Sridhar Ratnakumar]

On 09-06-23 02:57 AM, Nick Coghlan wrote:

Something like DistributionDirectoryMap should cover it.

You could probably get away with shortening "Directory" to "Dir" in the
class names though:

  - Distribution
  - ZippedDistribution
  - DistributionDir
  - ZippedDistributionDir
  - DistributionDirMap


'Map' reminds me of an associated hash (or is it the actual map?).

Hence I suggest: DistributionSet

-srid
___
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

Re: [Python-Dev] PEP 376 - get_egginfo_files

[Sridhar Ratnakumar]

On Sun, 05 Jul 2009 11:46:58 -0700, Paul Moore  wrote:


2009/7/5 P.J. Eby :

At 05:26 PM 7/5/2009 +0100, Paul Moore wrote:


def get_distribution(name):
   for d in get_distributions():
   if d.name == name:
   return d
   return None


Btw, this is broken code anyway, because it's not handling
case-insensitivity or name canonicalization.  (I've mentioned these  
issue

previously on the distutils-sig.)

Fair point. (Although I don't recall your distutils-sig posting, so
I'm not sure what you mean by "name canonicalisation").


Correct me if I'm wrong - I believe he was referring to the `safe_name`  
function:


  http://mail.python.org/pipermail/distutils-sig/2005-September/005120.html

-srid
___
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

Re: [Python-Dev] PEP 376 - Open questions

[Sridhar Ratnakumar]

On Wed, 08 Jul 2009 09:22:52 -0700, Paul Moore  wrote:


If the only driver for this PEP is setuptools, then I'm -1 on it.
Unless someone working on a packaging tool *other* than setuptools (or
setuptools-derived projects) speaks up and says "I have code of my own
which uses distutils, and I would benefit as follows from PEP 376 and
I will be changing my code to conform to PEP 376" I think the PEP
should be rejected, and the energy put into some other PEP which will
benefit the wider (non-setuptools) community.


Other than easy_install/pip, there is also PyPM which is being developed  
at ActiveState. PyPM is the Python package manager much like what ppm is  
for ActivePerl.


We build packages using 'setup.py install --root', but when it comes  
installation on client .. there is a separate database of installed  
packages that has the following information for each package installed:


   - metadata (name, version, author, etc..)
   - installed_files (list of files installed on client)

So "pypm remove Foo" will simply remove all the 'installed_files' of Foo  
and remove Foo from the package database. The package database is  
currently an sqlite-based one.


PEP 376 definitely will benefit PyPM besides benefiting setuptools/pip. If  
all package managers rely on common API to 1) retrieve metadata of  
installed packages 2) write metadata into site-packages), then it is very  
possible that one package manager does not mess up with the installation  
of others. For example:


  $ pip install IPython
  $ pypm install ipython

Without PEP 376, pypm will overwrite pip's installation. But with PEP 376,  
as pip writes the RECORD file, pypm will reuse it (via the API) and  
co-operate with it.


Eventually, I'd like PEP 376 to support system packagers too. So for  
example, if you did "apt-get install python-pyqt4", then running "pip  
install python-pyqt4" should return without installing anything .. as  
RECORD will be part of the .deb previously installed. As for generating  
the RECORD file, I vote for generating it during install time (w/ absolute  
paths).


-srid
___
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

Re: [Python-Dev] "Absolute" paths in PEP 376 RECORD files

[Sridhar Ratnakumar]

Is there any reason why RECORD file can't be generated at runtime? Also,  
why should the RECORD file be generated at all by bdist* commands?


A .deb file contains "data.tar.gz" that is simply extracted over "/".  
There is no need for RECORD inside a .deb file because it is implicit in  
the contents on data.tar.gz.


-srid

On Tue, 07 Jul 2009 13:30:05 -0700, P.J. Eby  wrote:

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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:  
http://mail.python.org/mailman/options/python-dev/sridharr%40activestate.com

___
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

Re: [Python-Dev] PEP 376 - Open questions

[Sridhar Ratnakumar]

On Fri, 10 Jul 2009 01:56:36 -0700, Paul Moore  wrote:


One thing that did occur to me based on this - do we want the format to
support designation of files (such as config files) that *shouldn't* be
uninstalled along with everything else? Or are we happy with not
mentioning the file in RECORD at all as the means of supporting that use
case?

No. In my view, the uninstall feature is a relatively minor issue -
people who want uninstall facilities generally use system packages (or
complain that easy_install doesn't support uninstallation :-)). They
aren't using setup.py install. (Of course, my experience is minimal in
this regard, so maybe I'm wrong).
Remember that the PEP says "Distutils will provide a **very basic**
uninstall function" (my emphasis).
Unless I'm misunderstanding, no-one is intending to use the new
distutils uninstall feature in their own package manager
(bdist_wininst, RPM, apt, ...)


Perhaps distutils can also provide an `uninstall` hook that application  
can use to do some pre-processing?



import distutils.installer
distutils.installer.register_uninstall_hoook(my_uninstall_hook)


I imagine that packages like pywin32 may have to register DLLs (install  
time) and unregister them (uninstall time).


Just a wild idea .. I understand that this may not be related to the  
current PEP. :-)


-srid
___
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

Re: [Python-Dev] PEP 376 - Open questions

[Sridhar Ratnakumar]

On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé   
wrote:



On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumar wrote:
Other than easy_install/pip, there is also PyPM which is being  
developed at
ActiveState. PyPM is the Python package manager much like what ppm is  
for

ActivePerl.



Great ! besides the RECORD file, anything remark on the PEP from a
PyPM point of view ?


I'll shortly send an email I composed regarding this.


Once Paul has finished to work on the PEP 302 part of the prototype,
maybe we could try it out
on PyPM to see how it fits ?


I took a look at PEP 302 and Paul's new implemention in pkgutil2.py

  http://bitbucket.org/tarek/pep376/src/tip/pkgutil2.py

And yes, I'd happy to try the new pkgutil API on PyPM .. keeping  
interoperability with pip/easy_install installed packages in mind.


-srid




___
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

[Python-Dev] PEP 376 - from PyPM's point of view

[Sridhar Ratnakumar]

Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)


Multiple versions: I understand that the PEP does not support
installation (thus uninstallation) of multiple versions of the same
package. Should this be explicitly mentioned in the PEP -- as
`get_distribution` API accepts only `name` argument, and not a `version`
argument?


get_distribution(name) -> Distribution or None.
Scans all elements in sys.path and looks for all directories ending
with .egg-info. Returns a Distribution corresponding to the .egg-info
directory that contains a PKG-INFO that matches name for the name
metadata.
Notice that there should be at most one result. The first result
founded is returned. If the directory is not found, returns None.


Some packages have package names with mixed case. Example: ConfigObj
.. as registered in setup.py. However, other packages such as turbogears
specifies "configobj" (lowercase) in their install_requires.

Is `get_distribution(name)` supposed to handle mixed cases? Will it
match both 'ConfigObj' and 'configobj'?


get_installed_files(local=False) -> iterator of (path, md5, size)


Will this also return the directories /created/ during the installation?
For example, will it also contain the entry "docutils" .. along with
"docutils/__init__.py"?

If not, how is the installer (pip, pypm, etc..) supposed to know which
directories to remove (docutils/) and which directories not to remove
(site-packages/, bin/, etc..)?


The new version of PEP 345 (XXX work in progress) extends the Metadata
standard and fullfills the requirements described in PEP 262, like the
REQUIRES section.


Can you tell more about this?

I see that PEP 262 allows both distributions names ('docutils') and
modules/packages ('roman.py') in the 'Requires:' section. Is this how
the new PEP is going to adhere to? Or, is it going to adhere to PEP
345's way of allowing *only* modules/packages?

In practice, I noticed that packages usually specify distribution names
in their 'Requires:' file (or install_requires.txt in the case of
setuptools). Hence, PyPM *assumes* the install requirements to be
distribution name. But then .. most distributions have the same name as
their primary module/package.

Ok, so PEP 345 also specifies the 'Provides:' header. Does
easy_install/pip make use 'Provides:' at all when resolving
dependencies? For example, does 'pip install sphinx' go look for all
distributions that 'provides' the 'docutils' provision.. or does it
simply get the distribution named 'docutils'?

-srid
___
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

Re: [Python-Dev] PEP 376 - from PyPM's point of view

[Sridhar Ratnakumar]

On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé   
wrote:



get_installed_files(local=False) -> iterator of (path, md5, size)


Will this also return the directories /created/ during the installation?
For example, will it also contain the entry "docutils" .. along with
"docutils/__init__.py"?


I don't think it's necessary to add "docutils" if
"docutils/__init__.py" is present

But for empty directories added during installation we should add the I  
guess.


So, I'll add a note.


It seems that you overlooked the below paragraph.


If not, how is the installer (pip, pypm, etc..) supposed to know which
directories to remove (docutils/) and which directories not to remove
(site-packages/, bin/, etc..)?


Quoting from the PEP:

[quote]'(...)uninstall uses the APIs described earlier and remove all  
unique files, as long as their hash didn't change. Then it removes empty  
directories left behind.'[endquote]


Let's assume that site-packages/ contained only one package 'Foo'. Will  
uninstall('Foo') remove the site-packages/ directory just because it  
turned out to be empty after removing 'Foo'? To explain, let's assume the  
RECORD of 'Foo' contains:


$ cat RECORD
Foo/__init__.py
Foo/bar/__init__.py
Foo/bar/test.py

and according to what you wrote in the PEP ("it removes empty directories  
left behind"):


$ python -m distutils.util.uninstall Foo
rm /.../site-packages/Foo/__init__.py
rm /.../site-packages/Foo/bar/__init__.py
rm /.../site-packages/Foo/bar/test.py
rm empty dir /.../site-packages/Foo/bar
rm empty dir /.../site-packages/Foo/
rm empty dir /.../site-packages/# !

it also remove the site-packages directory!

Then there is ~/python26/bin, ~/python26/include, ~/python26/etc, etc.. Do  
you see my point?



btw: is PyPM a public project ?


If by 'public', you meant open source, then no.

-srid
___
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

Re: [Python-Dev] [Distutils] PEP 376 - from PyPM's point of view

[Sridhar Ratnakumar]

On Wed, 15 Jul 2009 08:22:03 -0700, David Cournapeau   
wrote:



if docutils 0.5 is installed, Foo is broken, unless docutils 0.4 is
shipped with it.

As was stated by Debian packagers on the distutils ML, the problem is
that docutils 0.5 breaks packages which work with docutils 0.4 in the
first place.


Thus I am -1 on multi-version support .. and would rather have the python  
developers make their packages backward compatible just like what Armin  
did with Jinja and Jinja2. Debian at the moment has only one package  
"python-docutils" which is 0.5. How is a debian application supposed to  
depend upon 0.4? With Jinja, there is no problem .. there are  
'python-jinja' and 'python-jinja2'. Similarly, CherryPy should have gone  
with renaming their package names to CherryPy2 and CherryPy3.


-srid


PS: Quoting from a fellow developer:


> [...] it sounds like CherryPy 3.x is really an incompatible
> module that just kept the old name. That is rather unfortunate, but can
> sometimes happen.
 I have never seen a Python package changing its name (when significantly
changing API, design, etc..). The only exception that comes to my mind
is Jinja2 (renamed from 'Jinja'):
 [Armin] (...) Because we love backwards compatibility these changes will
go into a package called "jinja2"



Well, congrats to the Jinja team then!  The others will eventually learn...
Mixing incompatible APIs in a single namespace and using a non-standardized
version numbering system to keep things apart creates a world of pain!


The challenge however is in compartmentalizing versions according to
their major release numbers. Versioning in the Python world is already a
mess which we are beginning to sort out:
http://wiki.python.org/moin/Distutils/VersionComparison (PyPM relies on
this standard and the ongoing implementation - verlib.py)


How embarrassing for a cult that prides itself on having only one way for
everything they do...   CPAN versions numbers are just as much if not
more of a mess, but at least you can argue that it is the price for there
being "more than one way to do it".
___
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

Re: [Python-Dev] Update to Python Documentation Website Request

[Sridhar Ratnakumar]

On Thu, 23 Jul 2009 06:11:38 -0700, Jesse Noller  wrote:


Then why not include pip, easy_install, and this bash script I use to
install packages into core? The more the merrier, right?
Answer: None of these are standards, and as nick points out, there's
issues with sysadmins, security, and other things. Not to mention
they're fundamentally not part of the language.
At the language summit, this was hashed out quite a bit. I think most
everyone agreed that tools like easy_install, pip, virtualenv,
zc.buildout, etc simply do not belong in core python.


Once PEP 376 is implemented, my suggestion is to at least link to these  
tools (if not write a paragraph) as way of pointing users to alternative  
package managers that uses the 'uninstall' API. A mention of PyPI would  
also be helpful.


-srid
___
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

Re: [Python-Dev] 3to2 0.1 alpha 1 released

[Sridhar Ratnakumar]

On Wed, 26 Aug 2009 15:55:54 -0700, Joe Amenta  wrote:


-- 3to2 is now registered with PyPI.  Did I do it right?



http://pypi.python.org/pypi/3to2/0.1%20alpha%201


Please fix the version number to not contain any whitespace characters.  
Also set the `version` argument in setup(..) in your setup.py. And then  
you may want to use the `upload` command to upload the new tarball to  
PyPI. See http://wiki.python.org/moin/Distutils/Tutorial for more details.


-srid
___
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

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

[Sridhar Ratnakumar]

On Tue, 22 Sep 2009 15:48:08 -0700, Chris Withers   
wrote:




Since the language summit at PyCon 2009 various committers, including
me, have been encouraging Tarek to act as distutils dictator to get
things finished as we all know people are prone to bikeshedding that
would kill any forward momentum we have towards improving the
packaging situation.
 ...except that this isn't bikeshedding. Use of that term just to stifle  
productive discussion is also rude.


As I see it, the choice of syntax *as such* is an issue of bikeshedding  
except that the choice of one syntax over the another could make it  
supportive to add an useful feature in setuptools to distutils. For  
instance, this syntax which I proposed -  
http://mail.python.org/pipermail/distutils-sig/2009-September/013289.html  
- will make us think about adding install_requires/extra_requires to  
distutils *in addition to* the conditional metadata .. rather than  
inventing a new syntax to support only conditional metadata.


-srid
___
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

Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

[Sridhar Ratnakumar]

On Wed, 23 Sep 2009 10:11:18 -0700, Tarek Ziadé   
wrote:



On Wed, Sep 23, 2009 at 7:08 PM, Michael Foord
 wrote:
Note that Activestate also have a fledgling package management system  
for
Python (unreleased yet I *believe*) so it is probably worth reaching  
out to

them as well.

Yes I didn't mention it because the project is private afaik. I'll ask
them if it's planned
to be released.


PyPM is planned to be released to the public shortly after the planned  
2.6.3 release. Most likely during the first week of October.


-srid
___
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

Re: [Python-Dev] Python 2.6.3

[Sridhar Ratnakumar]

2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows  
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.


-srid

On Wed, 30 Sep 2009 05:34:02 -0700, Barry Warsaw  wrote:


On Sep 30, 2009, at 12:29 AM, Ned Deily wrote:


In my opinion, the standard python.org OS X installer for 2.6.3 now
"works well" on 10.4, 10.5, and 10.6 and is ready for release.


Fantastic, thanks.  Martin's uploaded the Windows binaries so I'll
make the announcement now.  No commits to the 2.6 tree are allowed
without checking with me first (via IRC, bug tracker or email).  I'll
make an exception for svnmerge bookkeeping.

-Barry



___
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

Re: [Python-Dev] Python 2.6.3

[Sridhar Ratnakumar]

On Wed, 30 Sep 2009 12:44:14 -0700, Barry Warsaw  wrote:

2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows  
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.

Thanks for the feedback!  Did you run the test suite on any of these?


I will run the tests sometime tonight and let you know.

-srid

___
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

Re: [Python-Dev] Python 2.6.3

[Sridhar Ratnakumar]

On Wed, 30 Sep 2009 13:06:47 -0700, Sridhar Ratnakumar  
 wrote:


On Wed, 30 Sep 2009 12:44:14 -0700, Barry Warsaw   
wrote:


2.6.3rc1 builds fine on Linux x86/x86_64, MacOSX 10.4 ppc/x86, Windows  
32bit/64bit, HP-UX, AIX and Solaris just like 2.6.2 did.

Thanks for the feedback!  Did you run the test suite on any of these?


I will run the tests sometime tonight and let you know.


No new significant failures have been found. (Some trivial issues have  
been reported in the bug tracker).


-srid

___
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

Re: [Python-Dev] a new setuptools release?

[Sridhar Ratnakumar]

On Wed, 07 Oct 2009 12:35:18 -0700, P.J. Eby  wrote:


At 07:27 PM 10/7/2009 +0200, M.-A. Lemburg wrote:
Having more competition will also help, e.g. ActiveState's PyPM looks
promising (provided they choose to open-source it) and then there's
pip.
 Note that both PyPM and pip use setuptools as an important piece of  
their implementation (as does buildout), so they are technically the  
competition of easy_install, rather than setuptools per se.
 IOW, putting setuptools in the stdlib wouldn't be declaring a victor in  
the installation tools competition, it'd simply be providing  
infrastructure for (present and future) tools to build on.


PyPM client relies on pkg_resources *only*[1]. Specifically for

1) the version comparison algorithm:

  $ grep pkg_resources pypm/client/version.py
  import pkg_resources
  return cmp(pkg_resources.parse_version(pkg1.version),
 pkg_resources.parse_version(pkg2.version))

2) parsing the "install_requires" string:

  $ grep parse pypm/client/dependency.py
  return [pkg_resources.Requirement.parse(reqstring)

Both these features are definitely worthy of addition to stdlib but only  
after *standardizing* them (like PEP 376 does with .egg-info structure and  
files list). Now that Distribute is getting some visibility, it will be  
extremely good for the community to add distribute-0.7 (which would  
include the above two features apart from others) to the stdlib.


-srid

***
[1] The backend code (our mirroring component) also uses  
setuptools.package_index


___
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

Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)

[Sridhar Ratnakumar]

On Thu, 08 Oct 2009 06:52:57 -0700, Michael Foord  
 wrote:


I don't recall ever having wanted / needed to install multiple versions  
of the same library - whilst I can appreciate that it *can* be a real  
issue it has never been a problem for me.


Multiple versions is going to be a mess. It is a pathetic workaround for
packages that do not care about backward compatibility (eg: CherryPy-2.x
vs CherryPy-3.x).  Drop support for multiple versions to force package
authors to deal with it.

I applaud the Jinja team for doing this:

ARMIN: The final version of the Jinja2 Django-inspired template
engine was just released. It comes with tons of improvements over
the older Jinja1 engine and breaks backwards compatibility to some
point over the old Jinja1 engine. It's packaged as a separate
package so that you can use both right next to each other for an
easier transition.

http://lucumr.pocoo.org/2008/7/17/jinja2-final-aka-jinjavitus-released

This is something the Python community can also learn from the Perl
world.

-srid

___
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

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

[Sridhar Ratnakumar]

On 12/27/2009 4:15 PM, david.l...@preisshare.net wrote:

On Fri, Dec 25, 2009 at 8:33 AM, Nick Coghlan  wrote:

>>  Martin v. Löwis wrote:

>  FYI we have introduced a range operator, so one may define a range of
>  versions.
>  This is useful for instance to write:
>
> Requires-Python: ~=2.5
>
>  Which means: requires any version of Python 2.5.x. This operator is
>  the default operator,
>  meaning that you can also write:
>
> Requires-Python: 2.5

I don't like the ~ at all sorry. The ~ operator is thoroughly confusing.

No application developer will quickly figure out what a tilde means. Maybe
it means 'roughly', but it requires too much thought and is ambiguous. 2.5
is not roughly 2.5.2. It is the same exactly.


Tarek,

I am a bit confused at the current proposal combined with the newly 
introduced range operator.


Would "Requires-Python: <=2.5" include 2.5.4 or not?

Also, "Requires-Python: 3" would include all 3.X versions, correct?

-srid
___
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

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

[Sridhar Ratnakumar]

On 12/27/2009 5:21 PM, MRAB wrote:

Tarek Ziadé wrote:

On Mon, Dec 28, 2009 at 1:41 AM, Sridhar Ratnakumar
 wrote:
[..]

Tarek,

I am a bit confused at the current proposal combined with the newly
introduced range operator.

Would "Requires-Python: <=2.5" include 2.5.4 or not?


<=2.5 means any version that is inferior or equal to 2.5.0 so 2.5.4
doesn't match


Also, "Requires-Python: 3" would include all 3.X versions, correct?


Correct, because, "Requires-Python: 3" is equivalent to
"Requires-Python: ~= 3"
which is equivalent to "Requires-Python: 3.x.x"


To me it's non-intuitive that "<=2.5" means <=2.5.0 but "2.5" means
2.5.x; it's not consistent, explicit is better than implicit, etc.


Yes. When we talk about Python-2.5 (as in, for instance, "this script 
requires Python 2.5 to run"), we are referring to 2.5.x, and not just 2.5.0.



I'd prefer it if omission means "don't care", so "2" means 2.x.y and
"2.5" means 2.5.x.


+1.

On 12/27/2009 4:37 PM, Tarek Ziadé wrote:
> As discussed in Distutils-SIG, 2.5 is not strictly equal to 2.5.2.
> That's exactly why we introduced
> the range operator. So one may make a clear distinction between
> "2.5.x" and "2.5".

Perhaps if "2.5" was instead considered to be a *range* of possible 
versions (2.5.0, ... 2.5.4), then this ambiguity wouldn't have arisen in 
first place?


Technically (Include/patchlevel.h), it is "2.5.0", not "2.5".

-srid
___
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

Re: [Python-Dev] Fwd: Download Page - AMD64

[Sridhar Ratnakumar]

On 1/12/2010 2:46 PM, Michael Foord wrote:

I presume the email below is about the Windows binary. Does the AMD64
release work on intel 64bit and can we make the wording clearer on the
download page?

The current description is " Windows AMD64 binary".


FWIW, we simply use (64-bit, x64).

  PlatformDownload
  ==
  Windows (x86)   Windows Installer (MSI)
  Windows (64-bit, x64)   Windows Installer (MSI)

https://www.activestate.com/activepython/downloads/

-srid
___
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

Re: [Python-Dev] Enhancing the shutil module

[Sridhar Ratnakumar]

On 1/17/2010 12:09 PM, Tarek Ziadé wrote:

On Sun, Jan 17, 2010 at 8:55 PM, Brett Cannon  wrote:

>  On Sun, Jan 17, 2010 at 11:51, Tarek Ziadé  wrote:

>>  Another module I would like to move away from Distutils is
>>  "archive_util". It contains helpers to build archives, whether they
>>  are zip or tar files. I propose to move those useful functions into
>>  shutil, as this seems the most logical place.

>  If it's archive-agnostic then shutil is probably the best place.

In more details:
It allows the creation of gzip, bzip2, tar and zip files through a single API.
There's a registry of supported formats and the API is driven by a
format identifier.


Will it also allow decompression of the said archive types? Distribute 
has some utility code to handle zip/tar archives. So does PyPM. This is 
because the `tarfile` and `zipfile` modules do not "just work" due to 
several issues.


See http://gist.github.com/279606

Take note of the following in the above code:

 1) _ensure_read_write_access
 2) *File.is_valid
 3) ZippedFile.extract ... issue 6510
 4) ZippedFile.extract ... issue 6609
 5) TarredFile.extract ... issue 6584
 6) The way unpack() detects the unpacked directory.

-srid
___
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

Re: [Python-Dev] Enhancing the shutil module

[Sridhar Ratnakumar]

On 1/17/2010 2:09 PM, Tarek Ziadé wrote:

>  Distribute has
>  some utility code to handle zip/tar archives. So does PyPM. This is because
>  the `tarfile` and `zipfile` modules do not "just work" due to several
>  issues.
>
>  Seehttp://gist.github.com/279606
>
>  Take note of the following in the above code:
>
>1) _ensure_read_write_access
>2) *File.is_valid
>3) ZippedFile.extract ... issue 6510
>4) ZippedFile.extract ... issue 6609
>5) TarredFile.extract ... issue 6584

Looks like some of these are already fixed (I just looked quickly in
the bug tracker though)


Only one of them was fixed (issue 6510), but the rest were either 
rejected or still open:


  http://bugs.python.org/issue6609 - catch special file errors
  http://bugs.python.org/issue6584 - catch CRC errors in gzip
  http://bugs.python.org/issue6196 - set permissions during extract


If its not already done and pending, it would be great if you could
refactor your fixes into patches for the remaining issues for each one
of those modules


I'd be happy to do so. This is what I am considering:

1) Patch Lib/zipfile.py to fix issue6609
2) Patch Lib/gzip.py and Lib/tarfile.py to fix issue6584
3) Patch Lib/tarfile.py to fix issue6196

I am hoping that (1) and (2) will get accepted. But not (3) - in which 
case, should this go as a workarond (_ensure_read_write_access in 
http://gist.github.com/279606) in the new, say, shutil.extract function?


-srid
___
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

Re: [Python-Dev] Enhancing the shutil module

[Sridhar Ratnakumar]

On 1/22/2010 2:44 PM, Tarek Ziadé wrote:

On Fri, Jan 22, 2010 at 11:17 PM, Sridhar Ratnakumar
  wrote:
[..]

>  3) Patch Lib/tarfile.py to fix issue6196
>
>  I am hoping that (1) and (2) will get accepted. But not (3) - in which case,
>  should this go as a workarond (_ensure_read_write_access in
>  http://gist.github.com/279606) in the new, say, shutil.extract function?

I agree with Lars conclusions on this issue, I don't think this
permission feature fits the sdtlib because its a very specific use
case.


Do you think anyone would want to use `shutil.unpack_archive` but 
*retain* the u-x,u-r permissions? I presume that one would - in most 
cases - want to *process* the unpacked archive .. especially when doing 
all this by writing a script.


To give an example, what if when Distribute uses `shutil.unpack_archive` 
to unpack a sdist from PyPI (the author generated the archive with 
u-r,u-x set on files/directoreis -- I've seen this happening before), 
the subsequent "python setup.py install" would fail due to permission issue?



Now, for shutil.unpack_archive, we could add a callable option (like
the progress_filter one)
that would be called with each newly extracted file, so one may apply
any process on it.


How about having an extra argument that would fix the permission? 
(Fixing the permission is only applicable for tarfile, not zipfile, 
hence even our callable will become specific to tarfile).


  >>> shutil.unpack_archive("/tmp/foo.tgz", "/tmp", make_readable=True)
  >>> help(shutil.unpack_archive)
  [...]
  If `make_readable` is True, then files with limited permission (cannot
  be read) will be fixed to make them readable by the current user.

-srid
___
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

Re: [Python-Dev] Enhancing the shutil module

[Sridhar Ratnakumar]

On 1/22/2010 3:19 PM, Tarek Ziadé wrote:

[..]

>  How about having an extra argument that would fix the permission? (Fixing
>  the permission is only applicable for tarfile, not zipfile, hence even our
>  callable will become specific to tarfile).
>
>>>>  shutil.unpack_archive("/tmp/foo.tgz", "/tmp", make_readable=True)
>>>>  help(shutil.unpack_archive)
>[...]
>If `make_readable` is True, then files with limited permission (cannot
>be read) will be fixed to make them readable by the current user.

That's still the same specific use case. Out of curiosity, how many
archives have you had the
problem with ?

If like I think, this is quite rare, I am -1 to introduce it that way
because you could handle with a generic callable as mentioned.


Yes, it is quite rare (I can recall maybe 2-4 packages having this 
problem). I see what you mean now. Since it is not a popular issue, 
adding this to stdlib may not be a good idea.


On 1/22/2010 2:44 PM, Tarek Ziadé wrote:
> Now, for shutil.unpack_archive, we could add a callable option (like
> the progress_filter one)
> that would be called with each newly extracted file, so one may apply
> any process on it.

Will this callable recieve TarInfo objects if the filetype is tarfile? 
What would it receive otherwise? How can `_ensure_read_write_access` be 
implemented using this callable? I cannot think of a design for this. 
(In that case, maybe then the permission setting would happen on the 
actual extracted files post-extraction).


-srid
___
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

Re: [Python-Dev] Enhancing the shutil module

[Sridhar Ratnakumar]

On 1/22/2010 4:38 PM, Tarek Ziadé wrote:

On Sat, Jan 23, 2010 at 1:15 AM, Sridhar Ratnakumar
  wrote:
[..]

>  Will this callable recieve TarInfo objects if the filetype is tarfile? What
>  would it receive otherwise? How can `_ensure_read_write_access` be
>  implemented using this callable? I cannot think of a design for this. (In
>  that case, maybe then the permission setting would happen on the actual
>  extracted files post-extraction).

Yes, I was thinking of a post-process on the file freshly created on the system


Or use os.walk. :)

-srid
___
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

Re: [Python-Dev] Python 2.6.5 rc 2

[Sridhar Ratnakumar]

I just verified with our ActivePython build that 2.6.4rc2 builds fine on Linux, 
Windows, Mac, HP-UX, AIX and Solaris. 3.1.2rc1 builds fine except on AIX[1] and 
HP-UX[2] but those issues existed in 3.1.1 too, I believe.

-srid

[1] http://bugs.python.org/issue6645
[2] http://bugs.python.org/issue5999

On 2010-03-09, at 4:56 AM, Barry Warsaw wrote:

> Hi Python hackateers!
> 
> It looks like we finally have no more release blockers for 2.6.5rc2.  I would
> like to tag the tree tonight for rc2 so that Martin can build the Windows
> installer for a release tomorrow.  I am also moving the final release back to
> Friday March 19.
> 
> -Barry
> ___
> 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/sridharr%40activestate.com

___
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

[Python-Dev] code.python.org - random 403 errors

[Sridhar Ratnakumar]

I am seeing random 403 errors when cloning the mercurial repositories of Python.

$ hg clone http://code.python.org/hg/branches/release2.6-maint
destination directory: release2.6-maint
requesting all changes
abort: HTTP Error 403: Forbidden
$ hg clone http://code.python.org/hg/branches/release2.6-maint/
destination directory: release2.6-maint
requesting all changes
abort: HTTP Error 403: Forbidden

Sometimes they work, sometimes not.

Should I report this issue to a specific tracker (other than bugs.python.org 
and webmas...@python.org)?

-srid

___
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

Re: [Python-Dev] code.python.org - random 403 errors

[Sridhar Ratnakumar]

On 2010-04-22, at 3:01 PM, Martin v. Löwis wrote:

>> In general python.org seems flaky today. Sometimes I could not reach the site
>> at all, now a ping to svn.python.org gives 30% packet loss.
> 
> Yes. See
> 
> http://www.python.org/munin/localdomain/localhost.localdomain-if_eth0.html
> 
> Somebody was consuming all bandwidth, although we couldn't quite figure
> out who (whenever I was looking, the traffic looked genuine). It turned
> out that Sridhar himself contributed a good chunk of this traffic.

Background in private emails to Martin (below):


On 2010-04-22, at 5:42 PM, Sridhar Ratnakumar wrote:

> 
> On 2010-04-22, at 2:13 PM, Martin v. Löwis wrote:
> 
>>> [snip ... ip address]
>>> 
>>> I must note that we do a nightly build of ActivePython using Python
>>> mercurial repositories for trunk, release26-maint and release31-maint
>>> (3 URLs) on 5 of our build machines. So one nightly build will make
>>> 3x5=15 "hg clone" requests per day to code.python.org. This week, I
>>> have been debugging the nightly build code (run by hudson); so that
>>> number is likely higher this week.
>> 
>> [snip ... possibly security-confidential part]
>> 
>> Can you please find a way not to clone the complete repository every
>> time? IIUC, it should be possible to update a clone, rather than
>> refetching it from scratch.
> 
> Ok, I setup a cron job to maintain an internal mirror of the above mentioned 
> repositories in code.python.org. We'll do a "hg pull -u" (equivalent to "svn 
> up") every hour; no clones. Hopefully, that should reduce the amount of 
> requests from our side. Let me know if in future this issue repeats.
___
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

Re: [Python-Dev] code.python.org - random 403 errors

[Sridhar Ratnakumar]

On 2010-04-22, at 10:55 PM, Jeroen Ruigrok van der Werven wrote:

> -On [20100423 02:48], Sridhar Ratnakumar (sridh...@activestate.com) wrote:
>>> Ok, I setup a cron job to maintain an internal mirror of the above 
>>> mentioned repositories in code.python.org. We'll do a "hg pull -u" 
>>> (equivalent to "svn up") every hour; no clones. Hopefully, that should 
>>> reduce the amount of requests from our side. Let me know if in future this 
>>> issue repeats.
> 
> Dirk Jan can probably correct me (or some other heavy Hg user) but for all I
> know you should indeed simply clone once and subsequently hg pull and from
> your local copy clone as you like. (At least that's also how
> http://wiki.services.openoffice.org/wiki/Mercurial/Getting_Started seems to
> aim at explaining.)

Since the "download Python source code" thing is just part of the ActivePython 
build script, and the Hudson build script deletes the "build/" directory of the 
previous build .. a clone was necessary. To fix this I ended up creating a 
"mirror" at a local site which mirror was maintained by an hourly 'hg pull -u'. 
The hudson build script still does a clone although from this local mirror URL.

(Incidentally, cloning from this mirror via the Apache index listing URL 
doesn't seem to work; gotta investigate why...)

-srid

___
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

Re: [Python-Dev] PEP 7 updated

[Sridhar Ratnakumar]

Nor did it break any of our ActivePython 2.7 (Python trunk) builds ... though I 
had to hand-edit the patches to use 4 spaces now. Will this untabification 
change be made to the `release2.6-maint` branch too?

-srid

On 2010-05-09, at 11:33 AM, Antoine Pitrou wrote:

> 
> Hello,
> 
> The untabification of C files didn't produce any noticeable problem on
> the buildbots.  I've updated PEP 7 with the mention that all C files
> should be 4-space indented, and removed the obsolete wording about
> some files being indented with tabs.
> 
> Regards
> 
> Antoine.
> 
> 
> ___
> 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/sridharr%40activestate.com

___
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

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

[Sridhar Ratnakumar]

On 2010-09-17, at 4:04 PM, Tarek Ziadé wrote:

> I am not even understanding what's the benefit of doing this since an
> egg_info directory is obtained at *build* time and can differ from a
> machine to another, so it seems pretty useless for me to publish this.

I am in full agreement with Tarek here. At ActiveState, we maintain our own 
index that differs from PyPI in two ways (among others):

- use setuptools.package_index to scrap sdists for packages that don't upload 
them to pypi
- PKG-INFO and requires.txt are extracted (if doesn't exist, generate using 
egg_info cmd) from each of the sdist

(and then our index provides the full metadata - with internal links to sdists 
- as a sqlite db for the builder processes on each platform)

The problem with extracting PKG-INFO and requires.txt on the index server is 
that, the contents of requires.txt sometimes differ based on which platform and 
Python version on which the egg_info command was run. For eg., the "tox" 
project depends[1] on "virtualenv" package if it is run using Python2, but not 
on Python3.

> The whole point of PEP 345 is to extend our metadata to statically
> provide dependencies at PyPI, thanks to a micro-language that allows
> you to describe dependencies for any platform.

Static metadata would allow packages like "tox" to configure Python version / 
platform specific dependencies without resorting to runtime checks. 

> We worked hard to build some standards, but if PyPI doesn't help us
> here, everything we did and are doing is useless.

Ideally, in future - I should be able to query static metadata (with 
environment markers[2] and such) for *any* package from PyPI. And this static 
metadata is simply a DIST-INFO file (instead of being a directory with a bunch 
of files in it). I don't really see a point in providing access to, say, the 
list of entry points of each package. As for as package managers is concerned, 
the only things that matter are a) list of package names and versions, b) 
source tarball for each release c) and the corresponding metadata with 
dependency information.

-srid

[1] http://code.google.com/p/pytox/source/browse/setup.py#30
[2] http://www.python.org/dev/peps/pep-0345/#environment-markers
___
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

Re: [Python-Dev] [Catalog-sig] egg_info in PyPI

[Sridhar Ratnakumar]

On 2010-09-18, at 2:29 AM, Thomas Lotze wrote:

> I'd like to expand [tl.eggdeps]
> to analyse dependencies between any packages on PyPI but I can't
> as long as dependency information is not available without actually
> installing things. [...]

On 2010-09-18, at 2:29 AM, Thomas Lotze wrote:

>> I am not even understanding what's the benefit of doing this since an
>> egg_info directory is obtained at *build* time and can differ from a
>> machine to another, so it seems pretty useless for me to publish this.
> 
> We do understand that legacy metadata has its issues, but taken with the
> appropriate amount of salt, it's better than nothing in most cases, enough
> so at least to solve some chicken-and-egg problems.

Just curious: aside from the static metadata issue which you recognize, how 
would you make tl.eggdeps analyze dependencies between any packages registered 
on PyPI  when not all of them upload their sdists (hence no egg_info) to PyPI?

Also, if I may ask, what is the intended use for tl.eggdeps? For use in package 
managers (buildout, pip)? If yes, then ... would providing egg_info in PyPI 
obviate the need for package managers such as pip to download sources before 
resolving dependencies (keeping in mind that even packages that do upload their 
sdists to PyPI sometimes end up not doing the same - perhaps out of 
forgetfulness - for theirs latest releases)?

-srid
___
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

Re: [Python-Dev] Buildbot for AIX

[Sridhar Ratnakumar]

On 2010-09-20, at 7:41 AM, Sébastien Sablé wrote:

> Le 17/09/2010 15:05, Antoine Pitrou a écrit :
>> Following on Martin's comments, you might also want to share things
>> with the ActiveState guys who, AFAIK, maintain an AIX version of Python
>> (but you have been the most active AIX user on the bug tracker lately;
>> perhaps they are keeping their patches to themselves).
> 
> I tried to find some source package or subversion repository on their web 
> site, but they only distribute binary versions.
> Also it is only the "Business Edition" that supports AIX and it is clearly 
> sold with a proprietary license.
> 
> So I doubt they would share their patches related to AIX, but I can always 
> ask.

Hi Sébastien,

We definitely like to share our core Python patches for AIX 5.1/5.2 and other 
platforms. We have, in the past, submitted a few of them already in the Python 
bug tracker.  As not all of them have been submitted (for lack of time), I 
uploaded them all here for your access,
http://gist.github.com/628519

Please do send us any patches you may have for building Python 3 on AIX.

-srid
___
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

Re: [Python-Dev] Porting Ideas

[Sridhar Ratnakumar]

On 2010-12-01, at 11:02 AM, Brian Curtin wrote:

> http://onpython3yet.com/ might be helpful to you. It orders the projects on 
> PyPI with the most dependencies which are not yet ported to 3.x.
> 
> Note that there are a number of false positives, e.g., the first result -- 
> NumPy, since people don't seem to keep their classifiers up-to-date.

Also note that the dependency information is incomplete. For instance, 
onpython3yet.com shows just 14 packages depending on "Twisted",

  http://onpython3yet.com/packages/show/Twisted

while, in reality, there are 68 of them,

  http://code.activestate.com/pypm/twisted/#requiredby
  (see the right sidebar)

-srid

___
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

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Sridhar Ratnakumar]

On Sunday, March 6, 2011 at 9:53 AM, Brian Curtin wrote: 
> On Sun, Mar 6, 2011 at 11:41, Michael Foord  wrote:
> - Hide quoted message -
> > I would like to see us create version specific (i.e. python32.exe / 
> > python32w.exe) binaries (or links if we drop support for earlier versions 
> > of Windows or some filesystems - I'm agnostic on that issue) *plus* a 
> > python3.exe / python3w.exe with "last install wins" (as it is for currently 
> > for file associations).
> > 
> 
> I don't have an ActiveState install on this machine, but I know they have 
> been adding some form of version specific binaries for a while, so maybe they 
> can comment on what they chose and how they chose it, and how people are 
> using it. Are Sridhar or Trent on here?
> 
 ActivePython for Windows includes the following binaries on Windows: 

* python.exe
* python3.2.exe
* python3.xe 
(plus the `pythonw` versions)

python3.2.exe is better than python32.exe because that matches the invocation 
(eg: "python3.2 -m foo") on Unix.

Similarly for 2.x (python2.exe / python2.7.exe).

All of this is particularly useful if the installer adds Python directory to 
%PATH% (which is the case for ActivePython, but not the one from python.org).

-srid ___
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