Mailman 3 October 2006 - Distutils-SIG

setting the right owner of local subdirectories
by Antoine Pitrou 25 Oct '06

25 Oct '06

Hi, Under Unix-alikes, you have to be root (thus using "sudo" or "su") in order to truly install a package (even with the "develop" command since it copies some info into the system directories). But an annoying side-effect is that, when you first run "sudo python setup.py develop" (or "install"), it also creates directories in the local directory under the root user. Which means that, when you later run commands that don't need to be root to be issued, you get the following kinds of error: $ ./setup.py test running test running egg_info writing flapflap.egg-info/PKG-INFO writing top-level names to flapflap.egg-info/top_level.txt writing dependency_links to flapflap.egg-info/dependency_links.txt writing entry points to flapflap.egg-info/entry_points.txt error: flapflap.egg-info/entry_points.txt: Permission denied It is a minor but repetitive annoyance. It would be nicer if, when creating those local subdirectories, setup.py would try to change the owner to the owner of the current parent directory (the project base directory). Regards Antoine.

3 3

easy_install --always-copy and setup.py develop
by Ian Bicking 24 Oct '06

24 Oct '06

I have a package (PasteDeploy) installed with "python setup.py develop", at version 0.9.7dev-r5544. There's a released version 0.9.6. When I do "easy_install --always-copy --install-dir /some/dir SomePackageThatRequiresPasteDeploy" it gives me errors like error: Could not find suitable distribution for Requirement.parse('PasteDeploy==0.9.7dev-r5544') (--always-copy skips system and development eggs) There is no requirement like that, it seems to be coming up with that version specifier on its own. If I try to install PasteDeploy specifically it works fine. If I remove that egg-link from develop it works fine. (Note: my end goal is to create a bundle of all the eggs that an app needs to run) -- Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org

2 2

SandboxViolation: open('/dev/urandom', 0) {}
by Joshua Boverhof 24 Oct '06

24 Oct '06

4Suite is listed as one of my project's setuptools "install_requires", but when I attempt to install on Mac OSX-10.4.8 using python-2.5 I get an error: """ Reading http://www.python.org/pypi/4Suite-XML/1.0 Best match: 4Suite-XML 1.0 Downloading http://cheeseshop.python.org/packages/source/4/4Suite-XML/ 4Suite-XML-1.0.zip#md5=0b61c214cd03ecb2f673b52b316c0a84 Processing 4Suite-XML-1.0.zip Running 4Suite-XML-1.0/setup.py -q bdist_egg --dist-dir /tmp/ easy_install-_X4a0x/4Suite-XML-1.0/egg-dist-tmp-uBG5YU error: Setup script exited with error: SandboxViolation: open('/dev/ urandom', 0) {} The package setup script has attempted to modify files on your system that are not within the EasyInstall build area, and has been aborted. This package cannot be safely installed by EasyInstall, and may not support alternate installation locations even if you run its setup script by hand. Please inform the package's author and the EasyInstall maintainers to find out if a fix or workaround is available. """ So setuptools isn't allowing 4Suite to access the random number generator during build/installation. I can easily subvert this, in case anyone else just wants to make this work: """ def main(): from setuptools import sandbox sandbox.DirectorySandbox._ok = lambda self,path: True """ Of course I'd like a better way of doing this, maybe I missed something in the setuptools docs on configuration? -josh

4 3

setuptools: but with svn-tag-revision and uncommitted project
by Ian Bicking 23 Oct '06

23 Oct '06

I get this exception when I run "python setup.py egg_info" with --tag-svn-revision and when the project has never been committed (and hence there's no committed-rev). I think it should instead give 0, or at least a good error message. (I don't see any problem with 0) Traceback (most recent call last): File "setup.py", line 24, in ? entry_points=""" File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 965, in run_command cmd_obj.ensure_finalized() File "/usr/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/usr/local/lib/python2.4/site-packages/setuptools-0.6c3-py2.4.egg/setuptools/command/egg_info.py", line 85, in finalize_options self.vtags = self.tags() File "/usr/local/lib/python2.4/site-packages/setuptools-0.6c3-py2.4.egg/setuptools/command/egg_info.py", line 179, in tags ): version += '-r%s' % self.get_svn_revision() File "/usr/local/lib/python2.4/site-packages/setuptools-0.6c3-py2.4.egg/setuptools/command/egg_info.py", line 227, in get_svn_revision localrev = max([int(m.group(1)) for m in revre.finditer(data)]) ValueError: max() arg is an empty sequence -- Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org

2 3

Problem with ihooks: not working as expected in Py25 with eggs?
by Giovanni Bajo 23 Oct '06

23 Oct '06

Hello, I'm using the following recipe (which I shall publish one day in the cookbook): ============== nobarepyc.py ========================= import ihooks import os class _NoBarePycHooks(ihooks.Hooks): def load_compiled(self, name, filename, *args, **kwargs): sourcefn = os.path.splitext(filename)[0] + ".py" if not os.path.isfile(sourcefn): raise ImportError('forbidden import of bare .pyc file: %r' % filename) return ihooks.Hooks.load_compiled(name, filename, *args, **kwargs) ihooks.ModuleImporter(ihooks.ModuleLoader(_NoBarePycHooks())).install() ============== nobarepyc.py ========================= This is useful when managing Python source trees with CVS/SVN: after a file is renamed or moved, you don't want imports to silently import the previously generated .pyc file. By importing this module in debug builds, you install an import hook that makes so a "bare" .pyc file (with no .py file next to it) is never imported. Now, this file does not seem to work with packages shipped as .egg files, at least in Python 2.5. Specifically, I get an import error with setuptools itself: >>> from misc import nobarepyc >>> import pkg_resources Traceback (most recent call last): File "<stdin>", line 1, in <module> File "C:\Python25\lib\ihooks.py", line 404, in import_module q, tail = self.find_head_package(parent, str(name)) File "C:\Python25\lib\ihooks.py", line 447, in find_head_package raise ImportError, "No module named " + qname ImportError: No module named pkg_resources *IF* I can read this traceback correctly, this has nothing to do with my own hook: it's ihooks itself which appears to be broken with .egg files. Is that correct? Does .egg files break ihooks? What is the correct way of writing this sort of import hooks with setuptools / .egg files? Thanks -- Giovanni Bajo

2 3

clean and swig/pyrex
by Eric Huss 23 Oct '06

23 Oct '06

I've noticed that the "clean" command does not remove files generated by swig or pyrex (since pyrex uses the same swig interface). Does anyone have any suggestions on how to make that work, or a suggestion on how to enhance distutils to make it work? -Eric

2 1

YAGNI extras and tests_require
by Jim Fulton 23 Oct '06

23 Oct '06

I'd like to call "Ya aint gonna need it" on the extras feature of setuptools. As far as I can tell, extras are just a way to avoid fine-grained packages. Is this benefit worth the complexity? I don't think so. It violates "There's Only One Way To Do It" and increases the complexity of setuptools. Setuptools is wonderful but it is complex. I think it would be helpful to make it simpler and I really don't see a need for extras. I think a similar argument could be made against the tests_require feature. (In the presence of the extras feature, it's puzzling that this isn't handled as an extra.) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

4 3

Re: [Distutils] YAGNI extras and tests_require
by Matt Good 22 Oct '06

22 Oct '06

Oops, I forgot to copy the list on my first respose. On Sun, 2006-10-22 at 14:45 -0400, Jim Fulton wrote: > Matt Good wrote: > > On Sun, 2006-10-22 at 13:52 -0400, Jim Fulton wrote: > >> I'd like to call "Ya aint gonna need it" on the extras feature of setuptools. > >> > >> As far as I can tell, extras are just a way to avoid fine-grained packages. > >> Is this benefit worth the complexity? I don't think so. It violates > >> "There's Only One Way To Do It" and increases the complexity of setuptools. > >> > >> Setuptools is wonderful but it is complex. I think it would be helpful to > >> make it simpler and I really don't see a need for extras. > > > > Well, I've found them to be useful with entry points in Trac plugins. > > For example the SpamFilter plugin provides several spam filtering > > methods, not all of which will be needed by every user. There's an IP > > blacklist filter that requires DNSPython. By declaring the entry point > > for the blacklist module with an extra for DNSPython the module will > > only load if that requirement is available. > > Why not just distribute the IP blacklist filter as a separate package? > > > > > I don't think it's uncommon for packages to have optional features that > > require additional dependencies, and extras provide an easy way to > > declare those dependencies. Sure, sometimes these features could be > > broken out into a separate package, but in the cases where I've used > > extras making additional packages would be the more complex solution. > > How more complex? You would simply have had more packages? Is that > really more complex that extras? Yes. An extra is simply a line or two in setup.py. A separate package means another branch in SVN, more releases to make, upload to the Cheeseshop, more files for users to download, and unneeded duplication between the original and new package. This seems like an awful lot of additional work just to justify removing a feature from setuptools. > Is it advantagous enough to violate TWOOWTDI? How does it violate that? There's *always* more than one way, but there should be one clear "right way", and I think extras *is* that way. There are clearly times when the right thing is to create a new separate package, but I think that new package should have sufficient substance and be decoupled from the original to justify distributing it separately. > Is it really worth this extra complexity in setuptools? Well, since Phillip is maintaining it I guess it's his decision. I think it's feature that's useful to developers, so I'm in favor of keeping it. -- Matt Good <matt(a)matt-good.net>

2 1

distutils doc page
by Ian Bicking 20 Oct '06

20 Oct '06

I was just noticing that the current distutils page (http://python.org/doc/current/lib/module-distutils.html) doesn't have any mention of setuptools or any modern packaging stuff. I think we should suggest that some links be added to that page. But in terms of creating a Setuptools package, I'm not sure what the best tutorial would be (I think the Setuptools docs are a bit more in-depth, and a link to a simpler and less comprehensive tutorial would also be good there). Suggestions for a tutorial to link to? -- Ian Bicking | ianb(a)colorstudy.com | http://blog.ianbicking.org

1 0

easier_install
by Ville M. Vainio 19 Oct '06

19 Oct '06

Someone here might have use for this (a trivial "wizard" for creating setup.py files): http://cheeseshop.python.org/pypi/easier_install/0.1 -- Ville M. Vainio - vivainio.googlepages.com blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'

1 0