Number of Python 3.x packages at the PyPI

[excord80]

Is there an easy way to see the number of PyPI packages which have
been ported to Python 3?

Are there any special arrangements necessary for PyPI packages which
have both a Python 2.x version and a Python 3.x version?

 

[Martin v. Löwis]

Is there an easy way to see the number of PyPI packages which have
been ported to Python 3?

Yes: browse all pacakges classified with

Programming Language :: Python :: 3

You can find them at

http://pypi.python.org/pypi?:action=browse&c=533

It seems that some package authors only classify with

Programming Language :: Python :: 3

Are there any special arrangements necessary for PyPI packages which
have both a Python 2.x version and a Python 3.x version?

So far, no such need has been identified.

Regards,
Martin

 

[skip]

Martin> http://pypi.python.org/pypi?:action=browse&c=533

Martin> It seems that some package authors only classify with

Martin> Programming Language :: Python :: 3

I did a release for lockfile yesterday which supports 3.0. I added the
"Programming Language :: Python :: 3.0" tag, but not the more inlusive tag
above. I just updated the information to include it so it now appears in
the search results.

Skip

 

[has]

So far, no such need has been identified.

I've had to fork my appscript project's codebase in order to add
support for Python 3.x. I would like to distribute both 2.x and 3.x
versions under the same package name for obvious reasons. This isn't a
problem with eggs as the Python version number is included in each
egg's name, but what about source distributions where both filenames
are exactly the same (appscript-0.19.0.tar.gz)?

Thanks,

has

 

[Martin v. Löwis]

I've had to fork my appscript project's codebase in order to add

support for Python 3.x. I would like to distribute both 2.x and 3.x
versions under the same package name for obvious reasons. This isn't a
problem with eggs as the Python version number is included in each
egg's name, but what about source distributions where both filenames
are exactly the same (appscript-0.19.0.tar.gz)?

I see. My initial reaction was that something should be done about this;
please do bring this up on (e-mail address removed).

On second thought: can't you just include the source of both versions
in a single source distribution file?

If you are going to release them in lock-step, you probably want to
always release both sets of sources together; if you don't release
them in lock-step, users will get confused how to obtain the most
recent release for 3.x (say) if some version has only the 2.x release.

Regards,
Martin

 

[excord80]

    Martin>http://pypi.python.org/pypi?:action=browse&c=533

    Martin> It seems that some package authors only classify with

    Martin>   Programming Language :: Python :: 3

I did a release for lockfile yesterday which supports 3.0.  I added the
"Programming Language :: Python :: 3.0" tag, but not the more inlusive tag
above.  I just updated the information to include it so it now appears in
the search results.

Skip

Should specifying the 3.0 tag implicity and automatically specify the
3 tag as well?

 

[Martin v. Löwis]

Should specifying the 3.0 tag implicity and automatically specify the

3 tag as well?

No. There is really no builtin automatic semantics to any of the
classifiers.

Regards,
Martin

 

[has]

I see. My initial reaction was that something should be done about this;
please do bring this up on (e-mail address removed).

OK, will do.

On second thought: can't you just include the source of both versions
in a single source distribution file?

The .tar.gz distributions are built by distutils/setuptools. If I
manually combine them into a single archive, I'm guessing that
'easy_install appscript' won't know how to read that custom archive
when building and installing from source. (Which also raises a further
question: if I do eventually manage to upload both 2.x and 3.x
versions under the same PyPI entry, will easy_install know which one
to download?)

Thanks,

has

 

[Martin v. Löwis]

On second thought: can't you just include the source of both versions

The .tar.gz distributions are built by distutils/setuptools. If I
manually combine them into a single archive

That's not what I'm proposing, though. Assuming you have two different
versions of your package, they should both live next to each other,
in a single root directory, e.g.

foo/
setup.py
bar_2x/
bar_3x/

Then sdist should package it all, through a MANIFEST.in, and
install/bdist/... should package it version-dependent:

if sys.version >= (3,0):
package_dir = {'bar':'bar_3x'}
else:
package_dir = {'bar':'bar_2x'}

setup(...
package=dir = package_dir,
...
)

I'm guessing that
'easy_install appscript' won't know how to read that custom archive
when building and installing from source. (Which also raises a further
question: if I do eventually manage to upload both 2.x and 3.x
versions under the same PyPI entry, will easy_install know which one
to download?)

See above. Won't this solve these problems? (although I don't know what
the "appscript" command does)

Regards,
Martin