Mailman 3 May 2010 - Distutils-SIG

problems building extension for Python2.6 using Visual Studio 2008
by Chris Withers 05 May '10

05 May '10

Hi All, I'm using: Python 2.6.5 Visual Studio 2008 I'm trying to compile a package (Twisted, as it happens) for Python 2.6 but having no joy: """ Setting environment for using Microsoft Visual Studio 2008 x86 tools. C:\Program Files\Microsoft Visual Studio 9.0\VC\bin>w: W:\>cd Twisted-10.0.0 W:\Twisted-10.0.0>c:\Python26\python.exe setup.py build running build running build_py running build_ext error: Unable to find vcvarsall.bat """ What am I doing wrong? cheers, Chris

1 0

Re: [Distutils] setuptools passing arguments/settings to dependencies' dependencies
by P.J. Eby 04 May '10

04 May '10

At 05:36 AM 5/4/2010 -0700, Kent wrote: >Something seems to have changed with a recent release of setuptools. >I recently upgraded to -0.6c11 from c9. > >Under c9, my setup.cfg could specify this: > >[easy_install] >find_links = ../../thirdparty > >in order to direct setuptools to install from the ../../thirdparty >directory instead of searching the internet. This worked for my >project's dependencies and the dependencies' dependencies. > >Now, under c11, settings in the setup.cfg only pass to my project's >direct dependencies (install_requires=[] list). > >They no longer are passed to those dependencies' dependencies. > >What happened? I've googled and googled and am having no luck. Is my >assertion correct? I need more information than this to understand what you mean. Are you talking about running from "setup.py install", or using "easy_install myproject"? What exactly are the dependencies, and the contents of the thirdparty directory? >P.S. I also can't find an official PEAK software setuptools forum... >is this the best forum to ask this question? From http://peak.telecommunity.com/DevCenter/setuptools#mailing-list-and-bug-tra… : "Please use the <http://mail.python.org/pipermail/distutils-sig/>distutils-sig mailing list for questions and discussion about setuptools"

2 1

setuptools passing arguments/settings to dependencies' dependencies
by Kent 04 May '10

04 May '10

Something seems to have changed with a recent release of setuptools. I recently upgraded to -0.6c11 from c9. Under c9, my setup.cfg could specify this: [easy_install] find_links = ../../thirdparty in order to direct setuptools to install from the ../../thirdparty directory instead of searching the internet. This worked for my project's dependencies and the dependencies' dependencies. Now, under c11, settings in the setup.cfg only pass to my project's direct dependencies (install_requires=[] list). They no longer are passed to those dependencies' dependencies. What happened? I've googled and googled and am having no luck. Is my assertion correct? Thanks to anyone who can help. P.S. I also can't find an official PEAK software setuptools forum... is this the best forum to ask this question?

1 0

setuptools --tag-revision poposed feature
by Manlio Perillo 03 May '10

03 May '10

Hi. Currently setuptools only support a ``tag-svn-revision`` option. However I use Mercurial, and I would like to tag hg revisions. Looking at setuptool sources, it should not hard to add a new ``tag-revision`` option, used, as an example: --tag-revision=hg In egg_info command class, then, the tags method could do something like: def tags(self): version = '' if self.tag_build: version+=self.tag_build if self.tag_revision: for ep in iter_entry_points( 'setuptools.tag_revision', self.tag_revision): version += '-r%s' % ep.load()() # Only use first entry point break elif os.path.exists('PKG-INFO'): version += '-r%s' % get_pkg_info_revision() if self.tag_date: import time; version += time.strftime("-%Y%m%d") return version The current ``--tag-svn-revision`` will become an alias for ``--tag-revision=svn``, and support will be directly available in setuptools. I don't know if setuptools is still under development (this topic seems quite confused, for me), but can I write a patch, hoping that it will be accepted? Where should I send the patch? Thanks Manlio

4 7

zc.buildout 1.5.0b1 and zc.recipe.egg.1.2.3b1
by Dave Peticolas 03 May '10

03 May '10

Thanks for the quick resolution of this, I just wanted to mention a problem I ran into with these that I don't think I saw reported in the archives. After working around the 'cannot import warnings' problem, I was getting errors where buildout complained about a missing find-links parameter. I set that to the empty value: [buildout] find-links = And then got the same thing with another one, can't remember which. I set that to the empty value, and then ran into a traceback about a parameter, I think it was 'include_site_packages' being passed to the working_set function that it didn't support. Sorry I can't be more specific about that, I was rebuilding my virtualenv several times, when it started working again thanks to the b2 releases. Since this was around the time the b2 versions were released, maybe it was a version mismatch between a b1 and b2 version? thanks, dave

2 2

Alternative to the default easy-install setup?
by skip＠pobox.com 03 May '10

03 May '10

> I suspect I've asked this before here but have forgotten the answer, so I > ask again. And just after sending I found Philip's response from about a year ago: http://mail.python.org/pipermail/distutils-sig/2009-March/011056.html I'll dig into that a bit. Skip

1 0

Alternative to the default easy-install setup?
by skip＠pobox.com 03 May '10

03 May '10

I suspect I've asked this before here but have forgotten the answer, so I ask again. We currently use easy_install at work to install most/all third-party packages. This causes problems because sys.path winds up organized like this: 3rd party stuff, followed by local stuff, followed by system stuff As the number of third-party packages grows, the startup time for most applications increases significantly because most of the modules and packages of interest are actually in the local stuff or the system stuff. If this was one or two applications running on a single machine it wouldn't be bad. When you add in NFS and try to start several hundred applications across a multitude of hosts it's pretty easy to freeze the NFS server for a non-trivial amount of time and extend startup times significantly. Our current hack is to comment out the import sys; new=... line which easy_install adds to the end of easy-install.pth. That's not perfect, since the next time a third-party package is installed we have to remember to do it again. And again. And again. Eventually, no matter how careful we are about this, someone forgets. There must be something I can do to mitigate this problem. Can all the third-party eggs be bundled into a super package of some kind to minimize all the file stat-ing? Would some other installer (pip? zc.buildout?) do things differently? Have I maybe missed some flags to easy_install which would improve things? Thanks, -- Skip Montanaro - skip(a)pobox.com - http://www.smontanaro.net/

1 0

Re: [Distutils] [issue1054967] bdist_deb - Debian packager
by Andrew Straw 03 May '10

03 May '10

I am moving the venue for this discussion on stdeb to the distutils-sig (from http://bugs.python.org/issue1054967 ). I think this is better discussed here. On 4/29/10 9:23 PM, Barry A. Warsaw wrote: > Manual moving/copying is what I want to avoid. I'd be totally happy with not reinventing the wheel if you think this would be easy to add to stdeb! Specifically: just create debian/ in place and do not build package. > OK, I just added a new command "debianize" to stdeb (git commit 3cac5533 on github). This is currently in the "debianize" branch, which I intend to merge into the master branch after a bit more review. > I have a few other minor suggestions, though if you think this isn't the best place to track them, please let me know where to submit them. > In general, the place is "Issues" at http://github.com/astraw/stdeb , but I've addressed all the issues below. > * Add setup.py entry_points so you don't have to use --command-packages > This (and all other dependencies on setuptools) was removed at the request of the distutils maintainer Tarek Ziadé, who suggested that depending on setuptools prevented listing stdeb in the stdlib distutils documentation. "--command-packages" is standard, documented distutils, and works fine in my experience. If it's convenience you're after, you can add this option to your ~/.pydistutils.cfg file as documented in the stdeb README.rst file. I'm not planning on re-introducing the old behavior. > * Package: shouldn't change dots to dashes. E.g. flufl.enum should be called python-flufl.enum > This should be fixed in git commit 24085bb. > * Update to Standards-Version: 3.8.3 > Thanks for the alert. I'll have a look. Added to the tracker at http://github.com/astraw/stdeb/issues/issue/25 > I'm happy to test whatever you come up with. > Great. If you want to write unit testing infrastructure, that'd be great. -Andrew

1 0

Re: [Distutils] problems with namespace package
by Manlio Perillo 03 May '10

03 May '10

Sorry for this reply, but it seems I have some problems at receiving mails from my gmail account. I have done some more tests and: * When installing in the system default site directory, namespace package work as expected * When installing in a virtual environment (virtualenv --no-site-packages), the namespace package is not found; it seems to be completely ignored Can someone else confirm that namespace packages do not work with virtualenv? Thanks Manlio

2 1

stdeb in Ubuntu 10.04
by anatoly techtonik 02 May '10

02 May '10

There is nothing critical I guess, but stdeb on Ubuntu 10.04 gives a lot of warnings about unknown "buildsystem" option and some others. Any hints why? Should/could these be fixed? pydoctor$ python setup.py --command-packages=stdeb.command bdist_deb .. Unknown option: buildsystem dh_testdir: warning: ignored unknown options in DH_OPTIONS .. dh_installinit Duplicate specification "O=s" for option "O" .. dpkg-deb: warning: 'debian/python-pydoctor/DEBIAN/control' contains user-defined field 'Python-Version' dpkg-deb: building package `python-pydoctor' in `../python-pydoctor_0.3-1_all.deb'. dpkg-deb: warning: ignoring 1 warnings about the control file(s) -- anatoly t.

1 0