Mailman 3 August 2012 - Distutils-SIG

Re: [Distutils] buildout 1.6 on windows
by Chris Withers 22 Aug '12

22 Aug '12

Hi All, At Alex's request: On 21/08/2012 23:56, Alex Clark wrote: > On Tue, Aug 21, 2012 at 6:46 PM, Chris Withers <chris(a)simplistix.co.uk > <mailto:chris@simplistix.co.uk>> wrote: > > Alex, > > On 21/08/2012 23:39, Alex Clark wrote: > > Perhaps I should re-release 1.5.2 as 1.6.2 until the windows > support > in 1.6 > gets sorted out. > > > Give me 24 hours to try and fix this please. I don't want to go > back to > 1.5.2 if we can help it. > > > How come you didn't properly test this before you released? > Seems like there have been a number of issues that have come up with > the 1.6 release that should have *really* been caught before it was > foisted upon people... > > > Can you please ask all of these questions on a list somewhere? I don't > want to get into it one-on-one, it's too long of a story. So, what's the long story? Buildout grows two new contributors and suddenly we don't care about quality and/or Windows support anymore? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 1

Re: [Distutils] buildout 1.6 on windows
by Chris Withers 22 Aug '12

22 Aug '12

On 22/08/2012 01:57, Alex Clark wrote: > On 2012-08-21 20:30:53 +0000, Chris Withers said: > >> Hi All, >> >> I'm pretty dismayed at the lack of QA that was done on the 1.6 release >> before it was released. >> >> I'm annoyed that the "latest" release of Buildout is completely hosed >> on Windows, and so I now see all my CI slowly turning red: >> >> http://jenkins.simplistix.co.uk/ >> >> When are we going to see a fixed release? Or do I really have to do >> and pin all my buildouts to 1.5.x?! > > > Fixed, sorry about that. Doesn't look like it... http://jenkins.simplistix.co.uk/job/testfixtures-buildout/124/PYTHON=2.7,la… Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

buildout 1.6 on windows
by Chris Withers 22 Aug '12

22 Aug '12

Hi All, I'm pretty dismayed at the lack of QA that was done on the 1.6 release before it was released. I'm annoyed that the "latest" release of Buildout is completely hosed on Windows, and so I now see all my CI slowly turning red: http://jenkins.simplistix.co.uk/ When are we going to see a fixed release? Or do I really have to do and pin all my buildouts to 1.5.x?! Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 2

[issue144] Improve per-user installation instructions
by Reuben Thomas 19 Aug '12

19 Aug '12

New submission from Reuben Thomas: The instructions for non-root use of EasyInstall appear to be out of date; specifically, they don't seem to take PEP 370 into account. My suggestion is that you replace the section called 'Mac OS X "User" Installation' with a section called "Home directory installation" and explain the PEP 370 method, which was implemented in Python 2.6, and works on all OSes. With a ~/.pydistutils.cfg like the following: [install] install_lib = ~/.local/lib/python$py_version_short/site-packages install_scripts = ~/.local/bin You can install packages to PEP 370 paths, including scripts, and you are using the same paths as if you use python setup.py install --prefix=$HOME/.local. You can then also remove the "Virtual python" section. Of course, some users may still want to use Virtual Python with easy_install, but they don't need special documentation to do so; they can just use the Virtual Python documentation. ---------- messages: 693 nosy: rrt priority: feature status: unread title: Improve per-user installation instructions _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue144> _______________________________________________

1 0

Buildout 1.6.1 released
by Alex Clark 19 Aug '12

19 Aug '12

Hi, Domen Kožar has fixed some regressions so we cut a 1.6.1: - http://pypi.python.org/pypi/zc.buildout/1.6.1#id9 Chris Lambacher has been working on the remaining Windows issues and had this to say in #buildout: "my assessement is that pretty much everywhere a safe string is used prior to going into Popen / subprocess.* that is wrong. The _safe_arg was introduced when os.spawnle was being used and the parameters(but not the executable) need to be quoted. subprocess handles that automatically if you give it an arg list (which is what is happening pretty much everywhere subprocess is being used)." If anyone with Windows experience could confirm and turn the above info into a patch, please let us know (e.g. via pull request on GitHub) Alex -- Alex Clark · http://pythonpackages.com

2 1

Buildout 1.6.0 : can't init new environment (I don't need bootstrap package)
by Takayuki Shimizukawa 19 Aug '12

19 Aug '12

Hi, I'm trying to create new buildout environment with zc.buildout-1.6.0, but...:: D:> python bootstrap.py -d init Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.28.tar.gz -snip- c:\users\taka\appdata\local\temp\tmpb0blmq\distribute-0.6.28-py2.7.egg Creating 'D:\\bo16\\buildout.cfg'. Creating directory 'D:\\bo16\\bin'. Creating directory 'D:\\bo16\\parts'. Creating directory 'D:\\bo16\\develop-eggs'. Generated script 'D:\\bo16\\bin\\buildout'. Installing py. Getting distribution for 'pycrypto'. warning: GMP or MPIR library not found; Not building Crypto.PublicKey._fastmath. error: Setup script exited with error: Unable to find vcvarsall.bat An error occurred when trying to install pycrypto 2.6. Look above this message for any errors that were output by easy_install. While: Installing py. Getting distribution for 'pycrypto'. Error: Couldn't install: pycrypto 2.6 D:> cat buildout.cfg [buildout] parts = py [py] recipe = zc.recipe.egg interpreter = py eggs = bootstrap Why `bootstrap` package was required? Ah, bootstrap.py invoke ``zc.buildout.buildout.main(['init', 'bootstrap'])`` (before buildout 1.6.0) but buildout-1.6.0 introduce init command sub parameter to accepts distribution requirements as like as ``python bootstrap.py init BeautifulSoup``. Does bootstrap.py require 'bootstrap' argument? https://github.com/buildout/buildout/blob/1.6.x/bootstrap/bootstrap.py#L156 -- Takayuki SHIMIZUKAWA

2 2

Buildout 1.6 release tomorrow
by Alex Clark 17 Aug '12

17 Aug '12

Hi, Please weigh in now if you have any serious concerns re: a Buildout 1.6 release, as described here: - http://blog.aclark.net/2012/08/13/bootstrapping-a-buildout-1-6-release/ Alex -- Alex Clark · http://pythonpackages.com/ONE_CLICK

5 6

py32, distutils, and __pycache__
by Marcus Smith 17 Aug '12

17 Aug '12

Hello: I'm working on the new pip release and have a few questions revolving around __pycache__, distutils, and distribute/setuptools Hopefully some people here can increase my understanding on this. btw, here's the specific pip issue this relates to: https://github.com/pypa/pip/issues/638 I've read thru PEP3147, so I have a basic understanding of the various import cases that it describes. using py3.2.2, pip1.1 and distribute-0.6.27... I want to confirm that all of the following are expected, normal and actually ok? I need to establish a baseline for the behaviors I should be working against. 1) after installing distutils distributions or setuptools distributions, I see inline *.pyc files (no __pycache__) 2) after importing one of the newly installed modules, I see the __pycache__ folder appear with a new compiled file, but the old inline pyc file for the module still remains 3) when using --record with --single-version-externally-managed with a setup.py using "setuptools", I'm finding that what get's used to generate the bytecode filenames is `setuptools.command.install_lib._bytecode_filenames`. This was a little surprising given that --single-version-externally-managed forces the use of 'distutils.command.install', so I was at first expecting `distutils.command.install_lib._bytecode_filenames` to be used. I think `distutils.cmd.Command.get_sub_commands()` is responsible for the use of `setuptools.command.install_lib` over `distutils.command.install_lib` in this case. 4) Both `distutils.command.install_lib._bytecode_filenames` and `setuptools.command.install_lib._bytecode_filenames` just generate inline *.pyc[o] filenames. I've seen this, http://bugs.python.org/issue11254, but I'm not clear on the whole story. Thanks in advance for any help, Marcus

1 0

Action on Metadata 1.2 edits?
by Daniel Holth 14 Aug '12

14 Aug '12

Python PEPs merged the Metadata 1.2 edits the first time, but they were backed out pending a discussion. Is a committer available to do one of the following? a) Let the Python PEPs maintainers know it's OK to merge the Metadata 1.2 edits (minus the X- fields) to allow Provides-Extra:, extra = conditions on Requires-Dist, and Setup-Requires-Dist b) Move these changes into a new Metadata 1.3 The edits are waiting to be pulled from https://bitbucket.org/dholth/python-peps/changeset/537e83bd4068c0235302b061… Thanks, Daniel Holth

1 0

man pages
by Ken Kundert 09 Aug '12

09 Aug '12

All, I am converting from the old setup tools to distribute and am having trouble with installing man pages for my project. The relevant part of my setup script is: setup( ..., scripts=['ec'], data_files=[ ('man/man1', ['ec.1']) ] ) When I would install using the --user options, it would put the executable in ~/.local/bin and the man pages in ~/.local/man. In this way, once ~/.local/bin is on my path, the man command would find the man page. However, when I use distribute, it is now putting the man pages in the egg (in ~/.local/lib/python2.7/site-packages/ec-1.0-py2.7.egg/man). The documentation seems to suggest that this is a feature rather than a bug, and I accept that, but man pages seem special, like scripts. They need to go into a particular place in order for the man command to find them, and putting them inside the egg is not helpful. Does anybody have a suggestion on how to get the man pages to end up where they belong? -Ken Sorry if this has already been discussed. I cannot figure out any easy way to search the mailing list archives for this information.

2 2