Mailman 3 August 2005 - Distutils-SIG

Message ("Your message dated Mon, 8 Aug 2005 12:00:37 +0200...")
by L-Soft list server＠clayart (1.8d) 08 Aug '05

08 Aug '05

Your message dated Mon, 8 Aug 2005 12:00:37 +0200 with subject "Message could not be delivered" has been submitted to the moderator of the CLAYART list: Mel Jacobson <melpots2(a)PCLINK.COM>.

1 0

Some questions about setuptools
by limodou 06 Aug '05

06 Aug '05

I'm new to setuptools. One question is: Recently I want to use setuptools for a project. My command line is just like : python setup.py sdist --formats=gztar But I found some deleted files also included in the package. These files are .pyc suffixed. I use subversion. I checked the setuptools' code, and found that setuptools indeed follows the .svn/entries file, but it only retrieves files, and check if the file is exist. But in my entries file, just like: <entry name="EasyElements.pyc" kind="file" deleted="true" revision="33"/> You can see the "deleted" field is "true", so the file should not be included in the package, even through the file is exist. So I think maybe the .pyc, .pyo file should be omited. The another question is: I have below directory structure: A/ setup.py B/ __init__.py b.py t.txt .svn/ entries So B is a package dir. But as I run setup.py, the t.txt is not include in the package. I followed the source code and found it was because that dir A hasn't in version control, i.e. there is not .svn directory in dir A, so the setuptools could not traversal the subdirectory. I don't know how to write my setup.py script. I'm sorry may be this letter is not suit for this maillist. -- I like python! My Donews Blog: http://www.donews.net/limodou New Google Maillist: http://groups-beta.google.com/group/python-cn

3 10

Re: [Distutils] Problems with Python eggs/setuptools
by Phillip J. Eby 05 Aug '05

05 Aug '05

At 07:29 PM 8/5/2005 +0200, Walter Dörwald wrote: >Hello Philip! > >I've started to play around with your easy_install script, since managing >our packages gets more complicated with each version. > >After I've installed setuptools via ez_setup.py I've tried downloading the >ll-xist package via "python -m easy_install ll-xist" but got a stack trace >instead (see the attached stacktrace.txt). The problem seems to be the >umlaut in my name. As PyPI requires UTF-8 encoded strings now, I've put a > author=u"Walter Dörwald".encode("utf-8") >in my setup.py when I registered the package (but a plain > author=u"Walter Dörwald" >in the setup.py in the package). > >To work around this problem it's possible to set the system default >encoding to Latin-1. I don't know if this is a problem with setuptools or >distutils, but doing a simple "python setup.py install" works. Note that this problem is a distutils problem writing PKG-INFO files; it's not anything specific to setuptools. I would recommend you use the .encode('utf-8') workaround until there is an official policy for the distutils to deal with encodings in PKG-INFO. >The other problem seems more severe: ll-xist is installed as the packages >ll.xist, but the package init file ll/__init__.py is *not* provided by >this package, but by the ll-core package instead. If I understood >http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages >correctly distributing subpackages via setuptools only works if the >package init file is empty, which it isn't in this case. Technically, you can do it, it's just not guaranteed that the non-empty one will be executed, unless it's first on sys.path. > Is there any workaround for this? You can distribute an identical __init__.py with each distribution that shares that parent package. If there is too much to duplicate, I would suggest moving the contents out to a module (e.g. _my_init.py), and then putting something like this in the __init__.py of each distributed package: import pkg_resources; del pkg_resources from _my_init import * and make sure that all the distributions that don't contain the _my_init module have declared a dependency to the one that does. The reason for the pkg_resources import is to ensure that it has a chance to set up the namespace package; if the modules were installed via a .pth file, and pkg_resources has not been imported yet, then the runtime system may not have made the package a namespace package yet, and it absolutely needs to be before the _my_init module gets imported, so that it will be on the package __path__. On occasion I've thought of maybe executing *all* the __init__ modules, but it seems potentially error-prone. If you want to try it, change this line in the _handle_ns routine of pkg_resources: module = sys.modules.get(packageName) or loader.load_module(packageName) to read instead: module = loader.load_module(packageName) and this will cause it to load *all* of the __init__ modules. However, the order of execution is still not guaranteed, and I'm not certain that it might not cause an __init__ to be reloaded if its grandparent directory is included twice on sys.path. Anyway, let me know if that change works for you, and I will think some more on the "load all __init__ modules" strategy. Even if I do implement it, I will want to mainly advise people to use empty __init__ modules for any new namespace packages they create.

1 0

pkg_resources: import string
by Ian Bicking 02 Aug '05

02 Aug '05

I was thinking some more about WSGI configuration, and much configuration involves some "import a string" routing, that looks like importstring("os.path:sep") or somesuch. But we implement it slightly differently. And maybe there could be a PEP and whatnot, but I don't even know what module that would go into, and it would just have to be backported for a long time anyway... but then it seemed like it would fit nicely into pkg_resources, and just about anywhere I want to import strings I expect pkg_resources to be around as well. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 3

Setuptools CVS broken for python2.3
by Vincenzo Di Massa 01 Aug '05

01 Aug '05

Is setuptools CVS going to work using python 2.3? After 25 of July it does not work anymore. I need it to build packages for both 2.4 and 2.3 . Should I stay on the 25 of July version? Thank you very much for this nice sftware. It is very usefull to use and to read its code to learn pythonic programming. Vincenzo

2 4

EasyInstall 0.4a1: now with PyPI autodownload
by Phillip J. Eby 01 Aug '05

01 Aug '05

I've just released a new version of EasyInstall, that supports automatic package location via PyPI; installing a package can now be as simple as: easy_install "SQLObject>=0.6" There are many new options and features related to this; see the EasyInstall home page for more information: http://peak.telecommunity.com/DevCenter/EasyInstall For the benefit of the PyPI maintainers, here is a summary of EasyInstall's fairly minimal assumptions about PyPI's current behavior, assuming that "base-url" is the root URL of the package index: * Going to "base-url/SomePackage" produces an HTML page that either has a title containing "Index of Packages" and links to zero or more pages for specific versions, or else it is a single-version package page. * Single-version package pages may have a home page and download URL link, each of which occurs after '<th>Home Page' and '<th>Download URL' respectively, if present. * Going to "base-url/" (note trailing '/') produces an HTML page containing links to all active versions of registered packages * Links to package pages always have URLs of the form "base-url/SomePackage/itsVersion" - i.e., exactly two path parts following the base URL, with no query strings, parameters, fragments, etc. EasyInstall should continue to work with PyPI if these assumptions continue to hold. However, I'd also like to suggest that PyPI deprecate the use of spaces and other non-alphanumeric characters (other than '-') in package names, and move to a case-insensitive matching mechanism for package names. (Currently, if a user types a package name in the wrong case, EasyInstall downloads the full package list in order to do its own case-insensitive search.) By the way, EasyInstall does not rely solely on the download URL of a PyPI entry, nor does it assume that the download URL is in fact the URL where the package's source distribution is found. Instead, EasyInstall inspects the URLs for whether the extension suggests an egg or source distribution. If not, it retrieves the listed URL, and if it contains HTML, it scans the HTML for links to egg or source distributions (again identified by extension). It does this for both the home page and the download URL, in case there is a usable download link on the package's home page. This approach was chosen to maximise the odds of successful downloading, given the current contents of PyPI.

1 1