Mailman 3 March 2006 - Distutils-SIG

[Distutils-sig] distutils charter and interscript
by John Skaller April 29, 2018

April 29, 2018

3 2

setuptools site-package pollution
by Anthony Tarlano Oct. 10, 2006

Oct. 10, 2006

Hi all.. Firstly, I would like to say thanks for the setuptools package, which I was introduced to after reading about the RuleDispatch package on the IBM developerworks charming python series. Oh btw. RuleDispatch is the most useful python package that I have seen in the last year in the python world, so thanks for that also ;) Now that the congrats and hugs are out of the way, I would like to ask a question. How can I tell setuptools not to put packages, such as dispatch, protocols, and setuptools, in a subdirectory named the same as the egg and to just put the package name. For example from pydoc I currently get: c:\python\lib\site-packages\ruledispatch-0.5a0.dev_r2100-py2.4-win32.egg dispatch (package) c:\python\lib\site-packages\pyprotocols-1.0a0dev_r2082-py2.4-win32.egg dispatch protocols (package) c:\python\lib\site-packages\setuptools-0.6a8-py2.4.egg easy_install pkg_resources setuptools (package) site what I would like to see is just: ..\site-packages dispatch (package) ..\site-packages protocols (package) ..\site-packages setuptools (package) Maybe it is just a pet-peeve, but I like to keep a nice tidy site-packages directory, and these long directory names just seem to me to be pollution of my site-packages directory in my command shell. If there is an option to have just the packages, I would really appreciate someone telling me what it is. If not maybe it could be considered, and to put whatever meta-data the directory names are providing somewhere else.. Thanks, Anthony

3 2

Further extending of setup.py
by Ian Bicking April 19, 2006

April 19, 2006

I'd like to get rid of the "paster" script, moving some of what it does into setup.py or elsewhere. To a degree that is possible, but I think requires some additions to setuptools: * An entry point group that is not globally looked up, like distutils.commands. This would be a set of commands the package provides only for itself. I expect it to look like: [distutils.commands.local] sql_record = sqlobject.manage.distextension:sql_record Exactly like what we have currently, just not looked up globally. * Additionally, or probably even better, something that enumerates locations for commands. E.g.: extra_commands=['SQLObject'] And then it would look in the SQLObject egg for distutils.commands.local, and apply everything found there to this package. Right now, for instance, buildutils adds a "pytest" command to every project, even though it only applies to some projects (for some commands this is ok, like "info", so two different entry points makes sense). A project could list itself to provide its own custom commands; I think that won't be too circular. Typically commands you provide for yourself or someone else are different -- e.g., the SQLObject commands don't apply to SQLObject itself. * Everything that can be done on a deployed egg will probably go in app/egg-specific command-line scripts, and maybe I'll make a little framework to make these easier to write, but that's entirely an implementation detail. But I'm also thinking that extra_commands could be used as a hint to that framework, and would kind of facilitate coordination of in-development commands with after-deployment commands. -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

2 5

Re: [Distutils] Breakage of fetch in setuptools-0.6a10-py2.4.egg
by Phillip J. Eby March 31, 2006

March 31, 2006

At 05:55 PM 3/30/2006 -0800, Grig Gheorghiu wrote: >Can I do it with a setuptools-aware setup.py installation file? > >I ran easy_install with the options you mentioned and it created >setuptools-0.6a11dev_r43297-py2.4.egg. I then tried to require this >version in setup.py like this: > > install_requires = ["setuptools==0.6a11dev_r43297", > ], A better way to do this is to do: from ez_setup import use_setuptools use_setuptools() And this will ensure that the user updates to 0.6a11 before running. See these links for more info: http://peak.telecommunity.com/DevCenter/setuptools#using-setuptools-without… http://peak.telecommunity.com/DevCenter/setuptools#managing-multiple-projec…

1 0

PyGraphViz
by natalie.l.doe＠gsk.com March 30, 2006

March 30, 2006

Does anyone have any experience using PyGraphViz or GraphViz on windows with python? We are having some trouble with compiling and wonder if anyone has had previous experience with this. Beyond just the compilation does anyone have any experience using PyGraphVix with PyQt? We are interested in the level of interactivity that can be achieved with the combination of the packages. Please e-mail back directly. Thanks!

1 0

Re: [Distutils] setuptools in fink
by Phillip J. Eby March 30, 2006

March 30, 2006

At 10:33 PM 3/29/2006 -0500, Kurt Schwehr wrote: >I think I have it figured out. Fink requires installing a package in a >temporary root install that is then turned into a deb. This makes the pth >files have bad paths. And if you use --single-version-externally-managed as well as --root, then it will not have bad paths. Also, 0.6a11 uses relative paths, and in any case defaults to using --single-version-externally-managed when you specify --root. >If I manage the paths in the pth files after the install, then things seem >to work. It looks like i will have to manage the easy_install.pth anyway >since if it ends up in a deb, then other packages can't work with it. I'm >going to create PostInstall, PostRm commands to take care of that. Don't go to all that trouble, it's not necessary. Just use 0.6a11 with "install --root" and you won't have to worry about any of this. If you run into any problems with it, let me know, as 0.6a11 is supposed to "Just Work" for system packagers using --root. If it doesn't, it's my fault, so tell me and I'll fix it. :)

2 1

Re: [Distutils] setuptools in fink
by Phillip J. Eby March 30, 2006

March 30, 2006

At 06:42 PM 3/29/2006 -0500, Kurt Schwehr wrote: >Phillip and others, > >Does this look like it is installed correctly? Or is it that I am calling >setup.py when I should be calling ez_setup? And what should I pass to >ez_setup? It does look like setuptools are installed incorrectly since >easy_install -h does not run. So what is the right way? If you are packaging setuptools for use with a system packager, you should use: python setup.py install --root=/some/pseudoroot If you are using setuptools 0.6a10 or earlier, you *also* need --single-version-externally-managed for this to work. 0.6a11 (which I just released a few minutes ago) automatically sets --single-version-externally-managed if you specify a --root, so you might want to just go ahead and upgrade, especially since 0.6a11 has a lot of other changes to improve compatibility with system packagers. For example, while 0.6a10 will complain about system-installed versions of a package as conflicting with a package that is being installed, 0.6a11 installs things such that there are no conflicts. 0.6a11 also supports making system packages for projects containing namespace packages, without causing inter-package conflicts for the packaging system.

2 1

setuptools 0.6a11 released!
by Phillip J. Eby March 30, 2006

March 30, 2006

This is a major new feature and bugfix release of setuptools, including: * Overhauled conflict management: no more -D/--ignore-conflicts-at-my-risk junk, it Just Works(TM). * Namespace package support that's compatible with system packagers * Lots of new setup() features including dependency_links (thanks to Tres Seaver), test_loader, and enhanced test_suite finder * Upload supports --identity (thanks to Stefan Behnel) * Improved error messages for unwritable cache directory, and added a special exception for wrapping such errors * Revision control plugin support * And a ton of minor bugfixes and creature comforts/"fit-and-finish" issues, ranging from version-specific "easy_install-2.x" executables to relative paths in .pth files. Please see the docs for details. Barring any new bugs, this should be the last 0.6 alpha release before we go beta. The 0.6 beta branch will then become a candidate for inclusion in Python 2.5 alpha 2, sometime in the next few weeks. So please report any issues as soon as practical. Thank you to everyone who reported problems, asked questions, and supplied patches.

1 0

Re: [Distutils] setuptools in fink
by Phillip J. Eby March 29, 2006

March 29, 2006

At 10:40 AM 3/29/2006 -0500, Kurt Schwehr wrote: >This makes me think setup tools is ok since it is in the default >site-packages: > >& /sw/bin/python2.4 >Python 2.4.2 (#1, Feb 24 2006, 17:05:21) >[GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin >Type "help", "copyright", "credits" or "license" for more information. > >>> from ez_setup import use_setuptools You didn't *call* use_setuptools, or import setuptools itself, so this doesn't actually mean that setuptools is okay. The error message below is displayed when use_setuptools() is *called*, not when it's imported. My guess is that setuptools isn't actually on the path, either because it didn't install correctly, or because the configuration for building SQLAlchemy doesn't specify that its build requires setuptools. >But then the SQLAlchemy build tries to pull down setuptools, which I don't >want it to do: > >CC=gcc-3.3 /sw/bin/python2.4 setup.py build > >--------------------------------------------------------------------------- >This script requires setuptools version 0.6a5 to run (even to display >help). I will attempt to download it for you (from ><http://cheeseshop.python.org/packages/2.4/s/setuptools/>http://cheeseshop.python.org/packages/2.4/s/setuptools/ >), but >you may need to enable firewall access for this script first. >I will start the download in 15 seconds. >---------------------------------------------------------------------------

2 1

Custom test loader support in setuptools
by Phillip J. Eby March 29, 2006

March 29, 2006

I've just added a ``test_loader`` keyword argument to ``setup()`` in setuptools' Subversion edition. This lets you specify a string of the form "modulename:classname" to specify an alternative to unittest:TestLoader for finding tests. Note that an instance of the specified class will receive a name that comes from the ``test_suite`` argument, but it is free to interpret that string in any way it wishes. For example, a "nose" loader class could be created that parses command line arguments from the test_suite string. The default test_loader is "setuptools.command.test:ScanningLoader", which scans submodules/subpackages for tests as well as invoking any module-level "additional_tests()" functions it finds. You can use a test_loader of "unittest:TestLoader" to force the old (non-scanning) behavior. And of course the field is wide open for people to create new test loaders, or wrap other testing frameworks as test loaders. Please see setuptools.txt in the source, under the "New and Changed ``setup()`` Keywords" section, for more details on the ``test_loader`` argument.

1 0