Just a short announce concerning the bdist_nsi mod:
It's an alternative way to build win32 package installer using Nsis.
This adds : Silent install, Modern UI, internationnalization, uninstall
Have a look at the screenshots!
It's still in early stage development but works quite well on all package I
tested without any modification as long as your setup.py is not esotheric
I'm happy to announce that an initial 0.1.0 version of Python Buildutils
The `buildutils` package contains extensions to Python's standard
distribution utilities (`distutils`) that are often useful during the
development of Python projects.
Buildutils was created to scratch an itch: removing ``make`` from the
Python development process and partially to gain a better understanding
of how `distutils` works.
The following extension commands are included:
send a release announcement to mailing lists
generate MD5 and SHA-1 checksum files for distributables.
generate an TAGS file over all packages and module (for use in
find lint using the pyflakes utility.
dumps information about the project.
push distributables and documentation up to a project site using
build Python documentation from restructured text documents and
Python doc strings.
run py.test unit tests.
dump statistics on the number of lines, files, modules, packages,
bring in a working version of a dependency (uses setuptools egg
For more information, including User's Guide, Command Reference, and
installation options, visit the Buildutils project site:
There's also a bit more information on the release at the
This is not wholly surprising, but py.test doesn't appear to run from
an egg. (I say it's not surprising, given that py is doing its own
import trickery...) The way it fails is interesting. I can import py
from a python prompt, but not from the py.test script.
Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import py.test
py lib is at /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py-0.8.0_alpha1-py2.4.egg/py/__init__.pyc
Traceback (most recent call last):
File "/usr/local/bin/py.test", line 4, in ?
File "build\bdist.win32\egg\pkg_resources.py", line 110, in run_main
File "build\bdist.win32\egg\pkg_resources.py", line 599, in run_script
line 3, in ?
ImportError: cannot import name py
Another of the pylib scripts, py.countloc, works fine. That one may
not depend on the rest of the package, though.
I'd thought I'd toss this out there in case anyone cares, but I'm not
sure if anyone will care about this particular case.
I've done some quick experimentation with py2app and packages
installed as eggs (stopping short of monkeying with py2app itself).
As it currently stands, py2app's dependency finder misses the
dependencies of modules within eggs. I was easily able to get my setup
script to copy the eggs I needed into the app's site-packages and
generate a .pth file to use the eggs, but found that the app wouldn't
run because of standard library modules that hadn't been included.
In some respects, eggsploding the egg's packages into a directory and
letting py2app pick the modules up from there is beneficial, because
that would probably include just a subset of the egg in the final app.
A smaller final app is a good thing. py2app also includes just the
.pyc files this way, whereas the eggs I have include the source.
I haven't tried py2exe yet, but I will probably end up with a similar approach.
Let's say you've got some libraries installed as eggs. If you run
py2app or py2exe on the application, it seems like you'd want the egg
(or at least it's contents) to come along with the application. Or, at
least, I'd prefer it for the eggs to come along with the app, rather
than being downloaded via require.
(For curiousity's sake, I just tried it and found that the contents of
the eggs were left behind when I ran py2app. Not at all surprising,
given that I don't think py2app or py2exe know about eggs yet...)
Anyone have opinions on how a standalone app should look with eggs?
I've just released setuptools 0.5a5, which updates the old "test" command
to do in-place build-and-test instead of the previous install-and-test
behavior. It also automatically require()s the package's dependencies, if
any, and updates the .egg-info metadata.
I also added a new "develop" command, which is like an install that doesn't
actually install the package. It runs "build_ext --inplace" (so that any C
extensions get built in the source directory) and then installs a .egg-link
pointing to the source tree, optionally updating easy-install.pth and
installing any dependencies for the package. (It only takes a subset of
the easy_install command options, however, so it's currently better if you
install your dependencies before using the "develop" command, especially if
you want to "develop" any of those as well.)
The "develop" command basically adds your source checkout to the eggs that
will be searched at runtime to resolve a 'require()' request, and if you're
installing to site-packages, then it will be added to sys.path as well
(unless you use --multi-version or -m). This lets you edit your source
checkout and do development without having to actually install the
package. Wrapper scripts are installed to the --script-dir; the wrappers
do a require() and then execfile() your in-development script source files,
so you don't have to re-run "develop" just because you've changed script
contents. The only time you need to re-run the "develop" command is when
your metadata (e.g. version or requirements) changes, or if you add a new
script, or need to rebuild changed C extensions.
When you're done with development, "setup.py develop --uninstall" will
remove the .egg-link and any easy-install.pth entry for your development
tree, but you will need to update or replace any installed scripts by hand.
All of these commands respect the standard distutils .cfg files, so you can
e.g. use setup.cfg to set options for developing and testing.
There were a couple of other important changes in this release;
easy_install the *module* is now found under setuptools.command;
easy_install the *script* no longer contains the actual command
code. Also, a new "egg_info" command was split out of "bdist_egg", so that
it could be used by "test" and "develop" as well as "bdist_egg". As a
result of this, "bdist_egg" no longer supports the various "tag" options
that it did before; you must now do something like this::
setup.py egg_info --tag-svn-revision bdist_egg
if you want to set tagging options. You can also use this with the
"develop" and "test" commands, e.g.::
setup.py egg_info --tag-svn-revision develop
in order to change the version info that will be used for the "virtual egg".
At this point, I think setuptools now has sufficient features to support
development of packages with "cheap" external dependencies. That is, a
package using setuptools to create its setup script can add external
dependencies with almost no effort on the part of the package developer,
and no effort at all for the package installer. And, with further effort
by persons familiar with the appropriate packaging systems, the dependency
information included in setup.py could be used to generate native packages
with dependency information (assuming there is some uniform mapping from
PyPI project names to platform package names).
In other words, I think we've now achieved an interim state of packaging
nirvana. There are many additional stages of enlightenment possible, but I
think we are now in a position to begin the journey. Of course, having
some docs would help quite a lot, as right now there's no formal
documentation for stuff like version/requirement syntax, how to specify
requirements in the setup() call, etc. I'd like to start upgrading my
existing packages to use the new features before I try and write any, but
if any brave souls happen to get to it first, well, the more the merrier
where docs are concerned.
The one area where docs might be a problem for a while is the actual
pkg_resources infrastructure, since I intend to do a major refactoring of
it in the 0.6 releases. In addition to restructuring based on the cleaner
concepts of distributions, environments, working sets, etc., it will also
be test-driven, such that nearly all the pkg_resources code will have unit
tests for it, and as much of the setuptools command code as possible will
too. I'll also be trying to clean up the older attempts at a dependency
management system that lurk deeper in setuptools; these never quite worked
out before. Finally, there are a few older features that are now of
questionable utility given the ease of adding external dependencies. But,
I'm not sure if I can remove any/all of these things yet, because I don't
know if anybody (besides Fred Drake and myself) has based anything
interesting on those features. So, those changes might have to wait for
the 0.7 release series, depending.
The original message was received at Tue, 5 Jul 2005 18:00:36 -0400
from csc.com [18.104.22.168]
----- The following addresses had permanent fatal errors -----
----- Transcript of session follows -----
... while talking to python.org.:
<<< 400-aturner; -RMS-E-CRE, ACP file create failed
<<< 400-aturner; -SYSTEM-F-EXDISKQUOTA, disk quota exceeded
Most (90%+) of the libraries I work with don't depend on a Python
version. But unfortunately when using easy_install/eggs they always
have an explicit version, and multiple installations are necessary
Generally speaking, all pure-Python packages are version independent.
At least on the source level. I suppose .pyc files aren't always
(though they haven't changed for a long time, have they?) -- would it be
reasonable to have version-independent packages?
Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org
Hi; trying to get back into this again...
So, there's a package at http://svn.saddi.com/flup/trunk/ that I want to
install, but it has no setup.py file. I think that file should look
from setuptools import setup
packages=['flup', 'flup.middleware', 'flup.resolver', 'flup.server']
And I'd probably add other things, but I think that's all that's
required. So... how should I make this happen? Should I hardcode
'http://svn.saddi.com/flup/trunk' into the setup.py file? Can I make
the location overrideable with an option? How do I download the
checkout? What was in a function before is now in
setuptools.package_index.PackageIndex, and involves all sorts of data
that doesn't seem to imply (because it's not a package without the
setup.py file, and there's no index to get it from).
Should I calculate r??? on my own, and if so where? Right before I call
setup()? I need the repository location to do so, so if the repository
location was overrideable then I'd need to get the real location.
Once the files are checkout out, how do I put it in place? Is there a
way to set the "base path" for the packages, so I could say "install
these packages, found in /tmp/wherever-it-was-downloaded-to"?
Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org