Distutils-SIG March 2011

distutils-sig@python.org

51 participants
61 discussions

Stop using setuptools or distribute in buildout (was Re: Fwd: Re: window 64bit madness)
by Jim Fulton 04 Apr '11

04 Apr '11

2011/3/19 Adam GROSZER <agroszer(a)gmail.com>: > Hello, > > As Jim wants to dump setuptools support from buildout, ... I don't want to, and won't until it gets too painful to support both. I just suspect that time is drawing near. I can also foresee a time at which buildout stops using either. That might be the best path for buildout....wow, the more I think of that, the more appealing it seems. Replacing use of setuptools/distribute could be a really nice project for a certain upcoming German buildout sprint. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

3 3

Re: [Distutils] reservations about pythonv
by Carl Meyer 03 Apr '11

03 Apr '11

This alternative approach (with a symlink and config file) sounds pretty good to me as well after our discussion at the sprints. The downsides I see: 1. Cross-platform inconsistency. Windows virtualenvs would be isolated from system python binary upgrades, *nix would not (some, like Brandon, consider this isolation a feature, so maybe *nix should allow that option too?) On the whole this doesn't seem like a big issue. 2. There would be no way to set LD_LIBRARY_PATH to include the virtualenv prior to execution of python. To be honest, I don't understand why this is needed, as current virtualenv doesn't do it and I haven't seen it break anything (compiled modules work fine in a venv). But people with more experience seemed to think it was needed at our open space discussion last Saturday. Perhaps someone can clarify what specifically breaks without this? I'll dive into this approach and see what I can achieve. I'd also appreciate feedback from Tarek or others familiar with the new sysconfig module about my changes there. Something along those lines will I think be needed with either approach, but I'm almost wondering if a new "virtual" install scheme would be a better approach? Carl Sent from my Android phone ----- Reply message ----- From: "Vinay Sajip" <vinay_sajip(a)yahoo.co.uk> Date: Wed, Mar 16, 2011 6:13 pm Subject: [Distutils] reservations about pythonv To: <Distutils-Sig(a)Python.Org> Barry Warsaw <barry <at> python.org> writes: > Here at the sprints we talked about several possible options, the details of > which of course will have to be hashed out. There will also be cross platform > considerations. I think on *nix at least, it would be nice if a symlink and > configuration file were enough to trigger the virtualenv behavior. I feel that this approach definitely has potential to be the most useful and practical. There's no reason for a separate executable if Python itself incorporates the virtual environment functionality, which is mostly about setting paths and environment variables. > For example, if I have a local 'python' symlinked to the real executable, with > a pythonv.conf file next to it, the virtual environment would be enabled. The > real Python binary would adjust its behavior in that case to know where the > standard library was, but also use the locally installed packages. Anyway, > that's how I'd *like* it to work on *nix, but it may have to work differently > on Windows, and it may have to work differently if environment variables have > to be set. Even if on Windows you have to copy rather than symlink, that could just be the main Python executable, which is not prohibitively large since the core of Python is in pythonX.Y.dll. Regards, Vinay Sajip _______________________________________________ Distutils-SIG maillist - Distutils-SIG(a)python.org http://mail.python.org/mailman/listinfo/distutils-sig

15 55

how to test distribute
by Adam GROSZER 31 Mar '11

31 Mar '11

Hello, I'd appreciate some hints how to run the tests of bitbucket.org/tarek/distribute/#0.6-maintenance and how to "test-drive" it. I want to check/fix the bug with win-amd64.exe's. That means I need to be able to somehow run "easy_install reportlab-2.5.win-amd64-py2.6.exe" -- Best regards, Adam GROSZER -- Quote of the day: Is this really happening?

2 1

buildout, setuptools, sourceforge problems
by Jeff Kunce 30 Mar '11

30 Mar '11

There seem to be some problems with packages on sourceforge not working with buildout. Something about sourceforge is sending two content-length headers. Anything the buildout gurus here can add? Description of problem. Suggests just eliminating sourceforge from allowed hosts: http://plone.293351.n2.nabble.com/buildout-dies-due-quot-invalid-literal-fo… Ticket at sourceforge: http://sourceforge.net/apps/trac/sourceforge/ticket/18486 Thanks. -- Jeff

2 1

Re: [Distutils] buildout, setuptools, sourceforge problems
by P.J. Eby 30 Mar '11

30 Mar '11

At 04:25 PM 3/29/2011 -0400, Jeff Kunce wrote: >There seem to be some problems with packages on sourceforge not >working with buildout. Something about sourceforge is sending two >content-length headers. Update your setuptools to 0.6c12dev-r88975 for the fix. (If you're using a forked setuptoools, you'll need to uninstall it first so it doesn't block your update.)

3 2

Re: [Distutils] easy_install doesn't work when there are multiple Content-Length headers
by P.J. Eby 29 Mar '11

29 Mar '11

At 10:08 PM 3/28/2011 +0700, Hoang Xuan Phu wrote: >Hi all, > >Just today I'm using easy_install to install mechanize and it is >failing with the error "ValueError: invalid literal for int() with >base 10: '382727, 382727'". By reading the source code and looking >at the headers I see that the server is returning 2 Content-Length >headers (same value, 382727), which is turned intoÂ '382727, >382727'. Fixing this should be very easy and I can do it then submit >a patch. I'm just wondering, as distutils seem to be in a forking >process, what's the best way to solve this? easy_install -U setuptools will update you to a version that fixes this, as I've already checked in a fix.

2 1

easy_install doesn't work when there are multiple Content-Length headers
by Hoang Xuan Phu 28 Mar '11

28 Mar '11

Hi all, Just today I'm using easy_install to install mechanize and it is failing with the error "ValueError: invalid literal for int() with base 10: '382727, 382727'". By reading the source code and looking at the headers I see that the server is returning 2 Content-Length headers (same value, 382727), which is turned into '382727, 382727'. Fixing this should be very easy and I can do it then submit a patch. I'm just wondering, as distutils seem to be in a forking process, what's the best way to solve this? Hoàng Xuân Phú

3 2

[issue124] Add support for installing test requirements to 'develop' command
by Tres Seaver 28 Mar '11

28 Mar '11

New submission from Tres Seaver <tseaver(a)palladion.com>: The attached patch adds a '--with-test-requirements' / '-t' option to the 'develop' command: the rationale is that when developing a package, one should be able to run the tests without polluting the local checkout directory with the eggs specified by its 'tests_require': those eggs should be installed just as the other ones mandated by 'install_requires'. I would actually prefer to make this behavior the default, perhaps with a command-line-switch to disable it, but think that backward compatibility trumps that itch. ---------- assignedto: pje files: setuptools-0.6-develop-with_test_requirements.patch messages: 606 nosy: pje, tseaver priority: feature status: unread title: Add support for installing test requirements to 'develop' command Added file: http://bugs.python.org/setuptools/file76/setuptools-0.6-develop-with_test_r… _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue124> _______________________________________________

1 0

What happened to Buildout documentation sprint?
by Ruslan Spivak 26 Mar '11

26 Mar '11

Hi, I just saw http://svn.zope.org/zc.buildout/branches/documentation/doc/how-tos.rest?vie… and the topic list looks very interesting. Was there any activity around Buildout documentation during the Buildout sprint? Ruslan -- Genius may have its limitations, but stupidity is not thus handicapped. - Elbert Hubbard

2 1

the usecase of continious integration based release-management (which could use more support on the ds2 side)
by Ronny Pfannschmidt 24 Mar '11

24 Mar '11

Hi, i'd like to propose making the work-flow of creating releases by just pushing vcs tags to a ci system as easy as possible personally all i ever want to do to release a new version is:: $vcs tag $version $vcs push currently that would require various nasty hacks to get the version meta-data static on sdist and to grab the version number in a setup hook there are various ways to ease this, the ones i imagined are a) provide a hook to get the version, make the version static on sdist/upload pro: straightforward, simple cons: kind of a hack b) provide support for multiple setup-hooks and support for command mixin's pro: generic way to do it cons: needs more code, more stuff in setup.cfg

6 7

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG March 2011