Re: [Distutils] The problem with Setuptools on Python 3.
At 02:26 PM 4/21/2009 +0200, Lennart Regebro wrote:
So why don't I use that for setuptools? Well, because:
c) The setup of setuptools requires setuptools. So to be able to do the 2to3 conversion in the setup, I need to first convert the source with 2to3. Yes, catch 22.
What I still don't get is why it can't work in a 2-stage process, running one setup.py with distutils to do the build_2to3, and then running a different setup.py to do the tests. I imagine that, if I were trying to support Python 3, what I would do first is make a Python 2 setuptools command that ran 2to3 on a setuptools-based Python 2 project, and generated a new source tree -- with all sdist-targeted content copied over, and all .py files converted (including setup.py itself)... and then ran whatever extra commands you gave, running Python 3 on the resulting setup.py, such that: python2 setup.py 2to3 test would automatically do the equivalent of cd build/2to3; python3 setup.py test after creating a converted distribution in build/2to3. That way, you could also do things like: python2 setup.py test 2to3 test to run the tests in Python 2 before converting and running them in Python 3. If somebody wants to create this command, perhaps that would be a good idea. It can of course be implemented as a plugin, so a change to setuptools itself is not required. In the simplest case, the command could just derive from sdist and build an sdist tree in build/2to3 each time, and then run 2to3 in place. Or it could reuse sdist and unpack the sdist into the build tree. This would be slower, but easier to code. A more advanced version could check for changes in SOURCES.txt between the original and the build/2to3 directory in order to find files to add/remove, and only run 2to3 on changed .py files. Something like: if not os.path.exists(target_sources_txt): # wipe build tree, build sdist and unpack target_manifest = load_manifest(target_sources_txt) for filename in target_manifest: if filename not in original_manifest: # delete file continue if is_older_or_nonexistent(filename): # copy or run 2to3 for filename in original_manifest: if filename not in target_manifest: # copy or run 2to3 ...but with a lot more os.path.join operations and a lot less handwaving. ;-) And the initial version of this could just always do the wipe-and-unpack step, although it'd still need to loop over the files to run 2to3 anyway, I suppose. Anyway, I know this is a fair amount of work; It just seems to me that it has more uses than converting setuptools; i.e., it'd be a useful rig for anybody doing 2-to-3 porting work.
On Tue, Apr 21, 2009 at 15:03, P.J. Eby
python2 setup.py 2to3 test
Well, yes, but it should be python 3 setup.py 2to3 test Otherwise it can't reasonably have any idea of which python to use. And when you run it with python3, the 2to3 command isn't needed, as the 2to3 step can be automatically inserted through version detection. In fact, this is exactly what I'm doing for zope.interface, as explained. For zope.interface, you run python2.5 setup.py test and it will test it with python2.5 You run python3.0 setup.py test and it will do exactly what you say: copy the files to build, run 2to3, and then run the test on that in-place. python3.0 setup.py install will copy the files to build, run 2to3 and then install it.
Anyway, I know this is a fair amount of work; It just seems to me that it has more uses than converting setuptools; i.e., it'd be a useful rig for anybody doing 2-to-3 porting work.
Yes. That's is exactly what I'm trying to achieve. And I aim to extend setuptools with build_2to3 and test_2to3 commands to do exactly that. But to do that I need a good setuptools distribution that supports Python3. And to do that, I need to make setuptools support Python 3 in a way that is acceptable to somebody who can merge it to trunk and make an official release. As far as I know that's you. If I can't find a solution that is both acceptable to you, and makes Python 3 support relatively painless, then my efforts have been in vain. Your comment about setuptools using itself as a good test case did make me think that this is the case. It explains why the test cases could run even though setuptools still couldn't install itself. I thought it was badly tested, now I know it's by design. Removing the self-dependency then means we have to write a whole bunch of new test cases. I do not have the energy to do this. As mentioned I have already put down a lot of effort into this, and I'm expac...experc... desperate and have given up. Even writing this email makes me all physically tired, besides taking a lot of time I should use to make money. I'm getting too old for this. Somebody else can do it. Over and out. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi All, Once a package is installed on a system... is there any way to find out where it was installed to? I am looking for both metadata and a directory name/path. In my Package Manager GUI, I want to be able to "reveal" all the hidden "goodies" that seem to dissapear into the subsystem. Either "Documentation" or "Demos" Here is an example.... C:\Python25\Lib\site-packages\win32\Demos or C:\Python25\Lib\site-packages\win32com\HTML Under Linux, it would be just as valuable. If not more. Regards David
On Wed, Apr 22, 2009 at 2:49 AM, David Lyon
Hi All,
Once a package is installed on a system... is there any way to find out where it was installed to?
Not at the moment. PEP 376 though, proposes a new API to be able to reach the metadata of an installed package, browsing the directories from the PATH (that's how setuptools does)
I am looking for both metadata and a directory name/path.
In my Package Manager GUI, I want to be able to "reveal" all the hidden "goodies" that seem to dissapear into the subsystem.
Either "Documentation" or "Demos"
Here is an example....
C:\Python25\Lib\site-packages\win32\Demos
or
C:\Python25\Lib\site-packages\win32com\HTML
Under Linux, it would be just as valuable. If not more.
There's no explicit way at distutils level to point things like documentation, maybe that could be a metadata. Maybe you can propose this, by commenting ths page : http://wiki.python.org/moin/Distutils/Metadata Regards TArek
Regards
David _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | http://ziade.org
On Wed, 22 Apr 2009 10:42:29 +0200, Tarek Ziadé
There's no explicit way at distutils level to point things like documentation,
Well I thank you for the answer. At least I have an answer from an expert..
maybe that could be a metadata.
Maybe you can propose this, by commenting ths page :
I would like to help but I'm not an expert in that area. A simple answer is that it would be good if the developer of a package could: - Register their documentation file ie index.html etc... - Register their examples directory - Register program executeables - (an example - ez_install.exe) otherwise it's easy for them to get lost. All other information seems to be available on Pypi in the DOAP record. Regards David
participants (4)
-
David Lyon
-
Lennart Regebro
-
P.J. Eby
-
Tarek Ziadé