[Distutils] [issue129] Installation problem with pyx on windows
New submission from Björn Lindqvist bjou...@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 setupto...@bugs.python.org
http://bugs.python.org/setuptools/issue129
___
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Option --show-response not working properly when uploading to PyPI
Hi,
When I try to upload a package to PyPI using the --show-response
option, I get the following result.
python setup.py sdist upload --show-response
Python 2.7 (r27:82500, Sep 16 2010, 18:03:06)
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Traceback (most recent call last):
File setup.py, line 31, in module
zip_safe=True)
File /usr/lib/python2.7/distutils/core.py, line 152, in setup
dist.run_commands()
File /usr/lib/python2.7/distutils/dist.py, line 953, in run_commands
self.run_command(cmd)
File /usr/lib/python2.7/distutils/dist.py, line 972, in run_command
cmd_obj.run()
File /usr/lib/python2.7/distutils/command/upload.py, line 60, in run
self.upload_file(command, pyversion, filename)
File /usr/lib/python2.7/distutils/command/upload.py, line 189, in
upload_file
self.announce('-'*75, result.read(), '-'*75)
TypeError: announce() takes at most 3 arguments (4 given)
Please CC me if you are responding to this message.
Thanks,
RHH
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On Wed, May 11, 2011 at 6:44 PM, Jim Fulton j...@zope.com wrote: On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Wed, May 11, 2011 at 3:21 PM, Jim Fulton j...@zope.com wrote: ... Not sure to folllow. You want to port Setuptools into py3k... again ? If so, this was done already in Distribute, and you can join the project. I don't really want to join a project. I already have a number of projects. But the work is not going to happen only into the zc.buildout tree, right ? Or you want to copy our work from Distribute back into Setuptools ? I would not mind of course, merging back the 2 projects would be awesome -- but I have no hopes on this. It's possible that I could reuse that work. I'd rather port to 23 rather than 3. That is, I'd rather not rely on 2to3 at deployment time. I find installing distribute in Python 3 to be really annoying due to the spew from 2to3. I also find the 2to3 development model really unattractive. The major benefit is that you don't have to maintain separate branches for py3. Another thing is that you often don't have to deal with 2to3 internals, as you just adapt your code to be 2to3 friendly I agree that extending 2to3 is tough, but that almost never occur. If it occurs, you just need to ask Lennart ;) And the benefits are larger than going manually. We tried ! I don't see the extra spew at install time as a problem. Although, my suggestion would be to start digging into the Distutils2/packaging project instead, since that will be in the standard library, and backported in 2.x. When it's mature, I'll use it. Some of the code you need is usable today. examples: - easy_install's package index can be replaced by the index tool we have. - browsing installed packages (the new PEP 376 and the old setuptools/distutils standards) - ... There are a few corner cases we don't deal with. For instance, we get things installed as non-zipped egg. I think that would be a good default for buildout2. But yeah, the code is not mature I guess, but it's driven by known use cases for you, not new features we'll ask people to try out. And it's going to be published in Python 3.3 in +1 year. Not sure what your roadmap looks like but if buildout2 is a rewrite, by the time its mature itself, 3.3 will be out imho I believe it provides all the features buildout needs. And if not we should add them Buildout needs entry points. Entry points are just a feature on the top of browsable metadata of installed packages. The browsable part is already provided by d2. The installation of custom metadata is going to be done this summer during the GSOC, Basically, a CUSTOM file in the metadata directory. With a backward compat layer to install entry point as custom metadata. In a new Python3.3/packaging based projects, people will be able to add in their setup.cfg file: [metadata] X-Entry-Points = group:name = here.it.is And this will be copied in project.dist-info/CUSTOM In fact the plan is to *publish* setup.cfg to PyPI so tools will be able to read it without downloading anything ! For you, it means that you could use a single API to browse metadata for every installed project, whether they are setuptools-based or distutils2-based. Regardless, I fully expect to use Packaging when it's ready, but I'm stuck with setuptools/distribute now. I so wish that fork hadn't been done. I so wished that we could have all worked together in the first place... On my side, the plan was to extend Distribute but that did not happen there, as we discussed the options in the Language Summit(s) and imo that was a good decision. Now I am looking forward to the new tools. But the reality is that some projects can run under Python 3 thanks to Distribute. It's now used in most major Linux distributions, and you saying I will not support anything else that setuptools in buildout2 does not sound right to me. By taking the road you've mentioned, it seems to me that it's going to be more work and trouble that you expect because: - you are going to re-do all the py3 porting we already did, and that needs backward compatibility w/ distribute, because some people use it for the extra python3 features we added - you are going to maintain several branches if you don't use 2to3 - what's going to happen when distutils2-based packages will be published ? are you going to add backward compat in setuptools, so redo what we did in d2 in reverse ? (this is planned in Distribute, so doubled-work again) A simple direction in my opinion would be: - make sure all stuff done on setuptools lately that were neglected on distribute side get merged back - so we really have 100% identical behavior that works under py3 that's *way* less work. - use when possible, pieces of distutils2 in buildout2, since we target backward compat for all our APIs. Because as far as I know, the Setuptools project is just doing bugfixing. I don't think there are yet new
Re: [Distutils] Buildout status
On Thu, May 12, 2011 at 6:56 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Wed, May 11, 2011 at 6:44 PM, Jim Fulton j...@zope.com wrote: On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Wed, May 11, 2011 at 3:21 PM, Jim Fulton j...@zope.com wrote: ... Not sure to folllow. You want to port Setuptools into py3k... again ? If so, this was done already in Distribute, and you can join the project. I don't really want to join a project. I already have a number of projects. But the work is not going to happen only into the zc.buildout tree, right ? No. If I do this, I'd work with Phillip Eby. If you tell me that distribute is being actively maintained, I'll use distribute. What I've heard in the past is that distribute wasn't being worked on. I'd interpreted this to mean that it wasn't being maintained. Perhaps I misinterpreted. Again, if you assure me that it is being maintained, I'll use it instead. ... Although, my suggestion would be to start digging into the Distutils2/packaging project instead, since that will be in the standard library, and backported in 2.x. When it's mature, I'll use it. Some of the code you need is usable today. Some isn't good enough. There's another issue that I'll mention below. examples: - easy_install's package index can be replaced by the index tool we have. - browsing installed packages (the new PEP 376 and the old setuptools/distutils standards) - ... There are a few corner cases we don't deal with. For instance, we get things installed as non-zipped egg. I think that would be a good default for buildout2. But yeah, the code is not mature I guess, but it's driven by known use cases for you, not new features we'll ask people to try out. And it's going to be published in Python 3.3 in +1 year. Not sure what your roadmap looks like but if buildout2 is a rewrite, by the time its mature itself, 3.3 will be out imho Buildout needs setuptools/distribute in 2 ways: 1. Buildout uses it to download and install packages 2. Buildout makes it available in the path when installing source distributions that import setuptools. It's going to be a *long* time before this need goes away. For a while, I was thinking of forking distribute to address #1, but that wouldn't address #2, which is just as importasnt. ... Regardless, I fully expect to use Packaging when it's ready, but I'm stuck with setuptools/distribute now. I so wish that fork hadn't been done. I so wished that we could have all worked together in the first place... What? I don't understand. You make it sound as if I refused to work with you. If you are suggesting that I failed to contribute to distribute or distutils2, you'll have to excuse me for choosing to work on other projects. Buildout is just a consumer of setuptools (and packaging in the future). ... But the reality is that some projects can run under Python 3 thanks to Distribute. True, including buildout. It's now used in most major Linux distributions, and you saying I will not support anything else that setuptools in buildout2 does not sound right to me. By taking the road you've mentioned, it seems to me that it's going to be more work and trouble that you expect because: - you are going to re-do all the py3 porting we already did, and that needs backward compatibility w/ distribute, because some people use it for the extra python3 features we added - you are going to maintain several branches if you don't use 2to3 - what's going to happen when distutils2-based packages will be published ? are you going to add backward compat in setuptools, so redo what we did in d2 in reverse ? (this is planned in Distribute, so doubled-work again) What I said was that I wasn't going to support both. Again, if you assure me that distribute is being maintained, then I'll avoid the work of porting setuptools to Python 3 and just use distribute. OTOH, if you tell me I have to wait for packaging to be widely adopted, well, that's just not going to cut it. A simple direction in my opinion would be: - make sure all stuff done on setuptools lately that were neglected on distribute side get merged back - so we really have 100% identical behavior that works under py3 I soo f%$#ing hate the fork. that's *way* less work. shrug - use when possible, pieces of distutils2 in buildout2, since we target backward compat for all our APIs. Because as far as I know, the Setuptools project is just doing bugfixing. I don't think there are yet new features in it. I consider that all setuptools-related technologies are now superseded by the new stuff we do in packaging (that greatly inherit from them) From talking to Phillip, I think he intends to update setuptools to reflect new peps. Personally, I'd be happy to see it (and distribute) just fix bugs and remain stable. I'm totally on board with the move to packaging, but until all of the packages that buildout needs to
Re: [Distutils] Buildout status
On May 12, 2011, at 09:28 AM, Jim Fulton wrote: If you tell me that distribute is being actively maintained, I'll use distribute. What I've heard in the past is that distribute wasn't being worked on. I'd interpreted this to mean that it wasn't being maintained. Perhaps I misinterpreted. Again, if you assure me that it is being maintained, I'll use it instead. FWIW, if buildout 2 only supports setuptools, it'll be much less interesting to me. Debian and Ubuntu use distribute by default, as does all of my own personal projects. Cheers, -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
Hello, On 05/12/2011 03:28 PM, Jim Fulton wrote: If you tell me that distribute is being actively maintained, I'll use distribute. What I've heard in the past is that distribute wasn't being worked on. I'd interpreted this to mean that it wasn't being maintained. Perhaps I misinterpreted. Again, if you assure me that it is being maintained, I'll use it instead. I fixed a bug some weeks ago. https://bitbucket.org/tarek/distribute/issue/200/win-amd64exe-cannot-be-installed I sort of dropped the lead to PJE too. The result is that distribute had the release in about a week, setuptools is nowhere. -- Best regards, Adam GROSZER -- Quote of the day: The most incomprehensible thing about the world is that it is comprehensible. - Albert Einstein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] third party program or python error
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___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On Thu, May 12, 2011 at 3:28 PM, Jim Fulton j...@zope.com wrote: On Thu, May 12, 2011 at 6:56 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Wed, May 11, 2011 at 6:44 PM, Jim Fulton j...@zope.com wrote: On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Wed, May 11, 2011 at 3:21 PM, Jim Fulton j...@zope.com wrote: ... Not sure to folllow. You want to port Setuptools into py3k... again ? If so, this was done already in Distribute, and you can join the project. I don't really want to join a project. I already have a number of projects. But the work is not going to happen only into the zc.buildout tree, right ? No. If I do this, I'd work with Phillip Eby. If you tell me that distribute is being actively maintained, I'll use distribute. What I've heard in the past is that distribute wasn't being worked on. I'd interpreted this to mean that it wasn't being maintained. Perhaps I misinterpreted. Again, if you assure me that it is being maintained, I'll use it instead. I can't spend anymore the time on it regularly unfortunately, I have to make choice about my free time and I chose to work in the stdlib upcoming package. But I can assure the following (that what happened lately) : 1- anyone that wish to contribute a patch can do it, I give commiter writes for this 2- we are now several people that can push a release at PyPI. I can add more people if I know them 3- When I do releases, I do post-review of patches 4- Some other folks have enough knowledge now to do 3. There are a few patches pending that should be commited, and I am not following Setuptools activity as I used too by a lack of time, so there are probably a few commits to backport. I think that's less of a day of work altogether as far as I can see. I can spent this time real soon and do a release so we're up to date, but you or someone else would need to help in the future. I don't know if this is a superior approach to PJE's approach on maintenanceship, but it means that any big issue that would happen in the code will not be locked by a single person. For instance OS packagers have an access to it, and can work out problems they had downstream. I don't think we're anymore on the no one can understand the code base line. ... I so wished that we could have all worked together in the first place... What? I don't understand. You make it sound as if I refused to work with you. If you are suggesting that I failed to contribute to distribute or distutils2, you'll have to excuse me for choosing to work on other projects. Buildout is just a consumer of setuptools (and packaging in the future). Sorry for the confusion, I was not pointing any finger at you. we referred to all parties involved for packaging tools, setuptools, distutils, distribute. I was just indirectly saying that I also wished we did not forked and be able to get along. But I am still glad we did since we offered setuptools for py3. ... - what's going to happen when distutils2-based packages will be published ? are you going to add backward compat in setuptools, so redo what we did in d2 in reverse ? (this is planned in Distribute, so doubled-work again) What I said was that I wasn't going to support both. But if a project supports only distutils2 in the future, you cannot force it to use setuptools' metadata. Yet, it will express dependencies you need to deal with. (PEP 345) ... From talking to Phillip, I think he intends to update setuptools to reflect new peps. Personally, I'd be happy to see it (and distribute) just fix bugs and remain stable. I agree for bug fixing. In the meantime I also partially agree w/ PJE: package_resources should be able to see packages installed by distutils2, o/w that's not going to work well I'm totally on board with the move to packaging, but until all of the packages that buildout needs to install switch away from setuptools, I have to be able to provide setuptools support. So do we. Packaging supports the installation of setuptools-based projects, and also reading metadata from project installed by it. ... IOW, unfork. I would *love* *LOVE* to see that happen. Me too, as long as we have more than one person on board :) - start to use in it, when possible, pieces of distutils2, so Distribute/Setuptools become PEP 345/PEP 376 aware shrug sure. That's reasonable. First, buildout has to get under control. That's my problem (and the problem of people graciously helping me). - stop adding features so distutils2/packaging slowly takes over Absolutely. I couldn't agree more. Just understand that we're going to have to support old packages that import setuptools in their setup scripts indefinitely. That's one of the biggest challenges I see. Maybe packaging can (does?) provide a shim for this. As I said earlier, we do have backward compat in everything we do with packages. That leads to ugly code in some places, but we have to. But as you
Re: [Distutils] Buildout status
On Thu, May 12, 2011 at 10:09 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: ... - stop adding features so distutils2/packaging slowly takes over Absolutely. I couldn't agree more. Just understand that we're going to have to support old packages that import setuptools in their setup scripts indefinitely. That's one of the biggest challenges I see. Maybe packaging can (does?) provide a shim for this. As I said earlier, we do have backward compat in everything we do with packages. That leads to ugly code in some places, but we have to. But as you said, there's the maturity problem... OK, given the discussion, I guess the easiest course for buildout would be for buildout 2 to support just distribute next (to simplify the code) and then work on transitioning to packaging. Buildout 1 would largely stay as it is with bug fixes. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
OK, given the discussion, I guess the easiest course for buildout would be for buildout 2 to support just distribute next (to simplify the code) and then work on transitioning to packaging. Buildout 1 would largely stay as it is with bug fixes. Tarek, correct me if I am wrong here, but 3rd party tools will need to rely on distribute(setuptools) as packaging/d2 will never provide a backwards compatible substitute or API. Packaging/d2 relies on distribute as an external dependency. So in this case buildout2 will need to support distribute and later add support for packaging down the road. So buildout2 will need packaging/d2 + distribute. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
At 10:29 AM 5/12/2011 -0400, Jim Fulton wrote: On Thu, May 12, 2011 at 10:09 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: ... - stop adding features so distutils2/packaging slowly takes over Absolutely. I couldn't agree more. Just understand that we're going to have to support old packages that import setuptools in their setup scripts indefinitely. That's one of the biggest challenges I see. Maybe packaging can (does?) provide a shim for this. As I said earlier, we do have backward compat in everything we do with packages. That leads to ugly code in some places, but we have to. But as you said, there's the maturity problem... OK, given the discussion, I guess the easiest course for buildout would be for buildout 2 to support just distribute next (to simplify the code) and then work on transitioning to packaging. Buildout 1 would largely stay as it is with bug fixes. You should be aware of a few things going forward, with respect to compatibility. While Distribute includes many changes that are not in setuptools; the reverse is also true: setuptools includes bug fixes that are not currently fixed in Distribute. One important fix is rather complex, as there was a problem with build-time dependency recursion that manifested itself as multiple bug reports for multiple packages. This was fixed in setuptools, but the Distribute developers opted not to port the fix when it first came out a year or two ago, and AFAIK that has not changed. So, you should be aware that you may have some non-trivial merge work ahead, if you want to include those fixes into Distribute. In addition, Distribute contains various pieces of anti-setuptools code, in the sense that it deliberately attempts to prevent setuptools being installed or updated. I don't know if you care about that one way or the other, but you should be aware that it exists. (And of course, there is 2to3.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
2011/5/12 Kelsey Hightower kelsey.highto...@gmail.com: OK, given the discussion, I guess the easiest course for buildout would be for buildout 2 to support just distribute next (to simplify the code) and then work on transitioning to packaging. Buildout 1 would largely stay as it is with bug fixes. Tarek, correct me if I am wrong here, but 3rd party tools will need to rely on distribute(setuptools) as packaging/d2 will never provide a backwards compatible substitute or API. Packaging/d2 relies on distribute as an external dependency. So in this case buildout2 will need to support distribute and later add support for packaging down the road. So buildout2 will need packaging/d2 + distribute. There are three concerns: 1 - tools used by zc.buildout itself to manage packages. 2 - what's imported in setup.py in every project 3 - the project's dependencies for 1, packaging only can be used in the long term since we provide backward compat. for 2, if setuptools is imported there, it's required of course. same for 3. Now for how packaging installs setuptools-based project, it's dealt at our level. IOW, zc.buildout in the long term will only have to deal with the packaging APIS and not worry about what we do internally. Practically speaking, What's not clear yet is how we will inform that we need that extra Distribute dependency. Last, for 2 and 3, if the project uses some APIs that are supposed to see all installed packages for example, it'll have to use Distribute once it has added the PEP forward compat layer (unless Setuptools also adds it, so both will work) I hope this is clear :) Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
