Mailman 3 May 2011 - Distutils-SIG

[issue129] Installation problem with pyx on windows
by Björn Lindqvist 12 May '11

12 May '11

New submission from Björn Lindqvist <bjourne(a)gmail.com>: H:\>easy_install pyx Searching for pyx Reading http://pypi.python.org/simple/pyx/ Reading http://pyx.sourceforge.net/ Reading http://sourceforge.net/project/showfiles.php?group_id=45430 Best match: PyX 0.10 Downloading http://sourceforge.net/projects/pyx/files/pyx/0.10/PyX-0.10.tar.gz/download Processing PyX-0.10.tar.gz Running PyX-0.10\setup.py -q bdist_egg --dist-dir c:\users\bjolin\appdata\local\temp\easy_install-jaiul5\PyX-0.10\egg-dist-tmp-4kffgf error: Setup script exited with error: SandboxViolation: mkdir('C:\\Python27\\share\\pyx', 511) {} 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. ---------- messages: 624 nosy: bjourne priority: bug status: unread title: Installation problem with pyx on windows _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue129> _______________________________________________

1 0

third party program or python error
by mikroman＠shaw.ca 12 May '11

12 May '11

This request may be beyond the scope of your help. I am trying to solve an issue that involves tix84.dll, a side-by-side error, .mp4 extension, and a wininst.exe that occurs from within Corel’s Paint Shop Photo Pro x3. An unusual request that may not involve Python at all, but, rather “some else’s programming.” – of course. I have scanned through Python’s FAQ’s and bug checker - as a side note I must say that I deeply respect the way this website is organized – truly brilliant and a lot of webmasters could learn from this layout. I can say that I am not a programmer. At least not advanced enough to be commercially successful. I would consider myself to be a competent bug checker yet I am stumped. I have included here a lot of information pertaining to this error. Would it be appropriate to send you error logs that might help? Python was included in Corel’s Paint Shop Photo Pro x3 version that I installed. Strangely the tix84.dll is not present in the Python dll library directory that is installed by PSP. I did locate that file from a known source and place it there which allows a certain PSP installation package to operate (which I believe is not supposed to occur in the first place); that would be wininst-8_d.exe which is present in the proper directory – yet Windows error log reports that it can’t find it. This installer wouldn’t continue without that dll. Now that it was able to continue and finish this peculiar installation, any attempt to start the program halts with “DetectLanguage()error. Exiting.” The program did function normally in every way it was supposed to previous to this odd installation. The strangest thing is that this installer was only initiated when I would attempt to open an .mp4 file in any fashion whether PSP was running or not. Until recently I would normally cancel the install operation and if I was running the application PSP would continue as usual. I ignored it. This was the first program I had installed after completely installing and updating a clean Windows 7 64bit on a new machine. The PSP program itself was further updated four times. This problem occurred before and after that procedure. Everything else that has been installed, 32 or 64 bit, has performed perfectly...well as perfect as humans can get. I have viewed the Corel message board and found several occurrences of this problem with no solutions provided. I will also post this to comp.lang.python seeking help. I would like to thank you now for taking your time to read this and I hope you can lead me in the right direction. Mike Loewen c=64 rulez

1 0

Support for multi-index ?
by Mathieu Leduc-Hamel 11 May '11

11 May '11

Hi all, i'm curious about the status of this "issue", is there any support in zc.buildout/setuptools for multiple index ? -- Mathieu Leduc-Hamel

3 10

Where is the reference of buildout options?
by Kevin Tran 11 May '11

11 May '11

Where is a reference to the buildout options? By options I am referring to parts, eggs-directory, find-links, eggs, etc. I have seen these in other peoples' config files, but where can I find the full list of options. I was unable to find it on http://www.buildout.org/docs/index.html.

2 1

[issue128] parse_version post-release tags do not work as expected
by Guy Rozendorn 10 May '11

10 May '11

New submission from Guy Rozendorn <guy(a)rzn.co.il>: according to http://peak.telecommunity.com/DevCenter/setuptools: >>> from pkg_resources import parse_version >>> parse_version('2.1-rc2') < parse_version('2.1') False but both setuptools 0.6c11 and 0.6c12dev_r88795 show that: In [7]: parse_version('2.1-rc2') < parse_version('2.1') Out[7]: True So pkg_resources acts the opposite of what the documentation says. ---------- keyword: pkg_resources messages: 623 nosy: guyroz priority: urgent status: unread title: parse_version post-release tags do not work as expected _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue128> _______________________________________________

1 0

Setuptools + specifying project's version
by Ruslan Spivak 09 May '11

09 May '11

Hi, In http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-… there is a statement that 2.1-rc2 means you've already released 2.1 and an example """ .... >>> parse_version('2.1-rc2') < parse_version('2.1') False .... """ Running the example gives quite the opposite result (setuptools-0.6c11): >>> parse_version('2.1-rc2') < parse_version('2.1') True and actually it turns out that a pre-release tag 2.1rc2 is equal to the post-release tag 2.1-rc2 >>> parse_version('2.1-rc2') == parse_version('2.1rc2') True Does anyone have any idea why that's the case or is it a bug? Cheers, Ruslan

3 2

[issue127] time.mktime simple checks fail when is_dst applies to the original timestamp
by yaneurabeya 09 May '11

09 May '11

New submission from yaneurabeya <yanegomi(a)gmail.com>: There's an optimization in pkg_resources.ZipProvider._extract_resource that checks the timestamp of a zip egg's files vs the os.stat output for the real file on disk (if it exists). time.mktime is used. The problem with using this function call with -1, is that if the underlying timezone is modified between the time that the file was installed, and the next time the file is being installed or the file itself was stored without a value relative to a timezone, the _extract_resource method will re-extract and install the new file, even if the contents are the same on disk. This generates more unnecessary I/O, and creates race conditions depending on how things are installed on disk. calendar.timegm can be used in its place, but it's not necessarily present on non-Unix platforms. A quick check that I ran shows that it's present on Cygwin, FreeBSD, Linux, and OSX however. ---------- messages: 622 nosy: yaneurabeya priority: feature status: unread title: time.mktime simple checks fail when is_dst applies to the original timestamp _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue127> _______________________________________________

1 0

virtualenv3
by Barry Warsaw 07 May '11

07 May '11

What's the current status of virtualenv3? When I search the Cheeseshop, I get two hits: http://pypi.python.org/pypi?%3Aaction=search&term=virtualenv3&submit=search It looks like Holger's virtualenv5 is a temporary fork of Brandon's virtualenv3 port. The latter seems to work fine for me on Ubuntu. I'd like to get a version of virtualenv3 packaged for Debian/Ubuntu, but I'm not entirely sure which one to use. Cheers, -Barry

3 8

Re: [Distutils] virtualenv3
by Laura Creighton 06 May '11

06 May '11

In a message of Fri, 06 May 2011 16:49:15 EDT, Barry Warsaw writes: >On May 04, 2011, at 11:15 AM, Carl Meyer wrote: > >>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase, >>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip. >>Try it out! > >So I have some more information on this. Debian Wheezy has 1.6 now, but > -p python3 still did not work. Here is the bug report: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D625784 > >The problem occurs when virtualenv.py re-invokes itself. As you know, Python >puts the script's directory in sys.path[0]. On Debian virtualenv.py is a >symlink to /usr/share/pyshared/virtualenv.py so it's /usr/share/pyshared >that gets put on sys.path[0] on the second invocation. That directory will >contain Python 2's version of pkg_resources.py which naturally causes the >traceback. > >OT1H, this bug is due Debian policy of symlinking its modules so that they >can be shared, which doesn't play nicely with virtualenv's re-invocation. >OTOH, >sys.path[0] isn't helpful in any case, and I can imagine some situations >where that could cause problems even on non-Debian systems. > >I've worked up a patch, which you can find in the above tracker, that just >deletes sys.path[0] when VIRTUALENV_INTERPRETER_RUNNING is 'true' and when >sys.path[0] == '/usr/share/pyshared' (the latter is just paranoia ;). >I've >verified this fixes the problem on Debian and doesn't seem to cause any bad >side-effects. I wonder if a similar patch shouldn't be applied upstream >though, to be sure that the re-invocation is insulated from the surrounding >environment? > >Another suggestion given was to put virtualenv.py in a private directory, >i.e. not in Debian's equivalent of site-packages. I don't know whether >there are other packages that try to import virtualenv.py though, so to >be safe, I just went with the sys.path hacking. > >Any thoughts? > >Cheers, >-Barry Holger will have an opinion on this. And I think tox http://codespeak.net/tox/index.html tries to import virtualenv.py . Laura

1 0

Re: [Distutils] virtualenv3
by Laura Creighton 04 May '11

04 May '11

In a message of Wed, 04 May 2011 14:05:47 EDT, Barry Warsaw writes: >On May 04, 2011, at 11:15 AM, Carl Meyer wrote: > >>Virtualenv itself supports Python 2.4 - 3.2 from a single codebase, >>beginning with the 1.6 release a few weeks ago, thanks to Vinay Sajip. >>Try it out! >> >>As far as I know neither virtualenv3 nor virtualenv5 will be developed >>anymore, as both were intended as stopgaps while virtualenv lacked >>Python 3 support. Holger or Brandon can correct me if I'm wrong there. > >Ah, fantastic, thanks! Debian sid has 1.6 so I'll get that sync'd for Ub >un= >tu >oneiric and put a back port in my PPA. > >Cheers, >-Barry If you want something that works with PyPy 1.5, you need 1.6.1 released on Saturday. 1.6 will not work. Laura

2 1

Distutils-SIG May 2011