[Distutils] How to get a list of package releases
[CC-ing this to distutils-sig, because it relates to setuptools as well, but please keep discussion on the catalog-sig if possible.] Hi, Maybe this is a stupid question, but how can I list all versions of a package that were registered on PyPI? For example, when I go to http://python.org/pypi/setuptools/ I'm redirected to the page of last version of setuptools. How can I check earlier versions of setuptools from there? I know this functionality is available for project admins, what about users? Another thing, some packages offer a development versions by giving a link to their subversion repository. Is there a way to list these extra install options on PyPI? By extra options I mean all non-standard version strings that will work with `easy_install package==version`, like common dev. Related setuptools question: is there a way to get list of available versions from easy_install? Cheers, mk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: Standard Declaration of tests in eggs
Hello all. I'm the primary author of nose. Michal Kwiatkowski was kind enough to point me to this thread, and I wanted to chime in with a few questions and answers. Apologies for pulling things from various parts of the thread together, I didn't want to send multiple replies all covering the same ground. Nose works fine with setuptools in source packages. It provides nose.collector for use as a test_suite with the test command, and a nosetests command that uses nose's own testrunner and supports loading options from setup.cfg. So for today's use I think it works pretty well. That's the good news. The bad: PJE wrote: (I'm not sure if nose really works with eggs, though; ScanningLoader will discover tests in eggs as long as the source is included, but nose may be strictly file-based for all I know. Changing it probably wouldn't be too difficult, however.) There's no explicit egg support and, unlike ScanningLoader, nose uses naive os and os.path functions to access the filesystem, so I think I'll need to supply a 2nd loader than uses pkg_resources. The loader must support a .loadTestFromName(name, obj) call, where name will be an empty string, and obj will be the object specified by a test entry point. The return value must be a unittest.TestSuite. And it must be possible to call the loader multiple times with different 'obj' values. This is broken in nose 0.9.x -- I have the logic of loadTestsFromName backwards, in that it only uses the module argument to determine the package context of the name to be loaded; if the name is blank and the module is 'foo' it will try to load tests from 'foo.' Not so good. It also currently is a generator that yields tests as they are loaded, rather finding them all and returning a TestSuite -- I don't know whether that will also be a problem. And nose currently uses imp.find_module and imp.load_module to import test modules, since that seemed to be the easiest way to handle the very common case of multiple test modules with the same name in different (non-package) directories. I don't know whether those will work correctly when importing from an egg. I'm hoping to fix all of these loader problems in the 0.10 series. I'll make whatever changes will be needed to support loading from eggs and the final form of this proposal (so long as that doesn't break anything that works now), but as you can see I'm going to need some guidance about what I need to do. JP ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] How to get a list of package releases
At 02:50 PM 1/18/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote: Related setuptools question: is there a way to get list of available versions from easy_install? The setuptools.package_index.PackageIndex class knows about all discoverable versions. However, this doesn't extend to versions that have been hidden by the package author. To have more than one discoverable version at the PyPI level, the author has to have made them visible in the admin interface. But, whichever ones *are* visible can be discovered by the PackageIndex class, along with any that are linked from the Home Page or Download URLs, or are linked on the package's PyPI page. More precisely, PackageIndex doesn't track versions; it tracks available *distributions*, which may include source distributions, SVN checkouts, eggs, .exe's, etc. But each distribution object carries version info determined from its filename. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] package_data issue (chopping off characters)
Hello,
I've just hit the problem that was mentioned in the thread with the
above title (see:
http://mail.python.org/pipermail/distutils-sig/2005-April/004453.html).
However, the email trail seemed to have hit a dead end and it wasn't
clear to me whether this had been flagged as a bug or whether it was a
problem with the way that setup.py was being used.
I've included a summary of the problem as I've encountered it below, but
would appreciate any clarification on whether this is a bug and I need
to wait for patched version, or whether it's a problem with the way I'm
using setup.py and there is a change/work around I can use.
Many thanks,
Jens
(this is being run on Ubuntu Dapper:Python 2.4.3 (#2, Oct 6 2006,
07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 )
I have the following directory tree
dir1/
setup.py
__init__.py
dir2/
__init__.py
doc/
test.txt
And the following setup.py:
#!/usr/bin/env python
from distutils.core import setup
setup(
packages=['dir1','dir1.dir2'],
package_dir = {'dir1': ''},
package_data={'dir1': ['doc/*.txt']}
)
I need this done in this way because of the way that my CVS repository
has been set up, with the root directory of the source (where the
setup.py script lives) also being the root directory of the package, and
I thought that the package_dir line above took care of that.
On running the script, however, I get:
[EMAIL PROTECTED]:~/dir1$ python setup.py install
running install
running build
running build_py
creating build
creating build/lib
creating build/lib/dir1
copying __init__.py - build/lib/dir1
creating build/lib/dir1/dir2
copying dir2/__init__.py - build/lib/dir1/dir2
creating build/lib/dir1/oc
error: can't copy 'oc/test.txt': doesn't exist or not a regular file
This appears to be caused by a bit in the function get_data_files in the
file:
/usr/lib/python2.4/distutils/command/build_py.py
specifically the line:
plen = len(src_dir)+1
If len(src_dir) is 0, which it is in my case, the first character of the
directory gets chopped off.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
