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:
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:
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
At 07:29 PM 8/5/2005 +0200, Walter Dörwald wrote:
>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
>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.
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
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.
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:
There are many new options and features related to this; see the
EasyInstall home page for more information:
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
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
This approach was chosen to maximise the odds of successful downloading,
given the current contents of PyPI.