Mailman 3 July 2005 - Distutils-SIG

bdist_nsi
by Jean-Christophe G. July 10, 2005

July 10, 2005

Just a short announce concerning the bdist_nsi mod: http://bdist-nsi.sourceforge.net/ 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

1 0

ANN: buildutils-0.1.0 - Distutils extensions for developing Python libraries and applications.
by Ryan Tomayko July 8, 2005

July 8, 2005

I'm happy to announce that an initial 0.1.0 version of Python Buildutils is available. 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: announce send a release announcement to mailing lists like python-announce-list(a)python.org checksum generate MD5 and SHA-1 checksum files for distributables. etags generate an TAGS file over all packages and module (for use in Emacs). flakes find lint using the pyflakes utility. info dumps information about the project. publish push distributables and documentation up to a project site using ssh/scp/sftp. pudge build Python documentation from restructured text documents and Python doc strings. pytest run py.test unit tests. stats dump statistics on the number of lines, files, modules, packages, etc. use bring in a working version of a dependency (uses setuptools egg stuff). For more information, including User's Guide, Command Reference, and installation options, visit the Buildutils project site: <http://buildutils.lesscode.org/> There's also a bit more information on the release at the lesscode.org blog: <http://lesscode.org/> Ryan Tomayko <rtomayko(a)lesscode.org>

3 10

Out of Office AutoReply: [CNET NETWORKS AV: VIRUS REMOVED] Delivery reports about your e-mail
by Jon Drukman July 8, 2005

July 8, 2005

I am out of the office until Monday July 11. Please contact Noel Morrison or Scott Bedard if your matter is urgent.

1 0

Something that doesn't run from an egg
by Kevin Dangoor July 7, 2005

July 7, 2005

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. /usr/local/bin/python 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.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 ? pkg_resources.run_main('py==0.8.0-alpha1', 'py.test') 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 File "/Library/Frameworks/Python.framework/Versions/2.4/bin/py.test", line 3, in ? import pkg_resources 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. Kevin

4 11

py2app and eggs
by Kevin Dangoor July 7, 2005

July 7, 2005

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. Kevin

1 0

eggs and py2app/py2exe
by Kevin Dangoor July 6, 2005

July 6, 2005

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

2 2

setuptools 0.5a5: "develop" and "test" commands
by Phillip J. Eby July 6, 2005

July 6, 2005

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.

2 3

RETURNED MAIL: DATA FORMAT ERROR
by dparson＠csc.com July 5, 2005

July 5, 2005

The original message was received at Tue, 5 Jul 2005 18:00:36 -0400 from csc.com [208.137.142.50] ----- The following addresses had permanent fatal errors ----- distutils-sig(a)python.org ----- Transcript of session follows ----- ... while talking to python.org.: >>> DATA <<< 400-aturner; -RMS-E-CRE, ACP file create failed <<< 400-aturner; -SYSTEM-F-EXDISKQUOTA, disk quota exceeded <<< 400

1 0

eggs: Python version independence
by Ian Bicking July 4, 2005

July 4, 2005

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 otherwise. 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

5 5

easy_install: setup.py-less packages
by Ian Bicking July 4, 2005

July 4, 2005

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 something like: from setuptools import setup setup(name="flup", packages=['flup', 'flup.middleware', 'flup.resolver', 'flup.server'] version='0.0-devel-r???') 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

3 5