Number of Python 3.x packages at the PyPI

E

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?
 
M

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
 
S

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
 
H

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
 
M

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
 
E

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?
 
M

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
 
H

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
 
M

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top