At 04:52 PM 4/22/2009 +0200, Lennart Regebro wrote:
On Wed, Apr 22, 2009 at 16:18, P.J. Eby wrote:
> Er, no. It only means that you need Python 2 to be installed
*while porting
> a package* to Python 3.
No. It means it needs to be installed when installing the package from
a source distribut
On Wed, Apr 22, 2009 at 16:18, P.J. Eby wrote:
> Er, no. It only means that you need Python 2 to be installed *while porting
> a package* to Python 3.
No. It means it needs to be installed when installing the package from
a source distribution. Which is the normal way of distributing
modules.
-
At 08:27 AM 4/22/2009 +0200, Lennart Regebro wrote:
On Tue, Apr 21, 2009 at 19:57, P.J. Eby wrote:
> At 04:06 PM 4/21/2009 +0200, Lennart Regebro wrote:
>>
>> On Tue, Apr 21, 2009 at 15:03, P.J. Eby wrote:
>> > python2 setup.py 2to3 test
>>
>> Well, yes, but it should be
>>
>> python 3 setup
Greg Ewing wrote:
> Tarek Ziadé wrote:
>> Please Greg, add your use case here with David's one, at the end of
>> the page,
>> since we are trying to work on a solution.
>>
>> http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
>
> Is this really the best place for it? My use case
> doe
Tres Seaver wrote:
> I don't know where you get the idea that setuptools / distutils is
> primarily about "building" software.
The main documentation of distutils says "building and installing python
modules". A large fraction of distutils code is related to building.
David
Tarek Ziadé wrote:
Please Greg, add your use case here with David's one, at the end of the page,
since we are trying to work on a solution.
http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
Is this really the best place for it? My use case
doesn't have anything to do with manife
At 04:06 PM 4/21/2009 +0200, Lennart Regebro wrote:
On Tue, Apr 21, 2009 at 15:03, P.J. Eby wrote:
> 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.
Why not? The 2to3 command could si
On Tue, Apr 21, 2009 at 15:03, P.J. Eby wrote:
> 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 au
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antonio Cavallo wrote:
>> And, as I frequently run into walls that make me thing setuptools
>> should be completely ignored, and then after fiddling about quite a
>> bit, find a way around it, and then run into the next wall, etc, etc,
>> etc. And thes
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 i
On 21 Apr, 2009, at 14:31, Eric Smith wrote:
Ronald Oussoren wrote:
On 20 Apr, 2009, at 22:12, Lennart Regebro wrote:
I'm sorry you feel that way, as I've been *trying* to help. I
just still
don't get what the problem is. If I were porting setuptools to
Python 3, I
would *want* it to b
Ronald Oussoren wrote:
On 20 Apr, 2009, at 22:12, Lennart Regebro wrote:
I'm sorry you feel that way, as I've been *trying* to help. I just
still
don't get what the problem is. If I were porting setuptools to
Python 3, I
would *want* it to be circular, even if I had to hack on it a little
On Tue, Apr 21, 2009 at 14:15, Ronald Oussoren wrote:
> I don't understand why not, doing it may be not entirely trivial but it
> should be possible with some trickery. As PJE noted one way to do this is
> to explicitly convert setuptools to python 3.x syntax before actually
> running setup.py (e
On 20 Apr, 2009, at 22:12, Lennart Regebro wrote:
I'm sorry you feel that way, as I've been *trying* to help. I just
still
don't get what the problem is. If I were porting setuptools to
Python 3, I
would *want* it to be circular, even if I had to hack on it a
little at
first. So I hav
SuSE runs a build service for free and support automatic rebuild of
packages from sources:
https://build.opensuse.org
For anyone interested you can find the lates svn python snapshot under:
http://download.opensuse.org/repositories/home:/cavallo71:/python-opt/
Each subdirectory (CentOS_5, RHE
Maybe we should stop talking about how to improve distutils under the
topic of what the problem is with setuptools under Python 3? It's
pretty unrelated. ;-)
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
__
On Tue, Apr 21, 2009 at 11:17 AM, David Lyon wrote:
>> But it's quite a work...
>
> I think it is very important to put this software infrastructure into
> place.
>
> or at least include it in some sort of plan going forward
>
> have the server farm report build bugs back to the maintainers...
On Tue, 21 Apr 2009 09:21:12 +0200, Tarek Ziadé
wrote:
> I had this idea of running a test server that would listen to PyPI and
> get every new package to build it and test it on various platform/python.
>
> I think this could be done right now, with how distutils works,
>
> It requires creat
Eric Smith wrote:
> Tarek Ziadé wrote:
>> Please Greg, add your use case here with David's one, at the end of
>> the page,
>> since we are trying to work on a solution.
>>
>> http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
>>
>
> Could the people adding the use cases put their name
Tarek Ziadé wrote:
Please Greg, add your use case here with David's one, at the end of the page,
since we are trying to work on a solution.
http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
Could the people adding the use cases put their names by them, so if we
have questions
> One thing you guys should also consider is automated building/testing
> of packages. On different platforms.
>
> Let me give you a practical example...
>
> package win32...
>
> latest version.. no longer works on windows 2000...
>
> only works on xp... or vista...
>
> Bad for me.. takes me time t
>> Please Greg, add your use case here with David's one, at the end of the
> page,
>> since we are trying to work on a solution.
>>
>> http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
I can identify three major areas of concern:
1) Platform testing/builds (via cloud computing)
On Tue, Apr 21, 2009 at 08:44, Tarek Ziadé wrote:
> Please Greg, add your use case here with David's one, at the end of the page,
> since we are trying to work on a solution.
>
> http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
I realized another usecase, which may or may not be c
Please Greg, add your use case here with David's one, at the end of the page,
since we are trying to work on a solution.
http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
On Tue, Apr 21, 2009 at 7:19 AM, Greg Ewing wrote:
> Lennart Regebro wrote:
>
>> We need a plan. Somebody plea
Hi Lennart,
Sorry for my late posting...
I'm working on a gui python package manager on sourceforge...
> Executive summary:
> I have catch 22 problems in finishing the setuptools port to Python 3,
> and unless somebody can come up with alternatives, I may rip out
> setuptools dependency on itsel
Lennart Regebro wrote:
We need a plan. Somebody please make a plan
Whatever plan you come up with, I'd like to see the
basic architecture built around a dependency graph,
at least for the parts concerned with building
extension modules from sources.
My use case for handling Pyrex sources. I'd
Tarek Ziadé wrote:
>
> In the short term, Distutils needs to be a better citizen when people
> wants to extend it, so they can do it without re-writing everything.
>
> You have this experience of "pain", share it through real use cases.
>
I have added 5 usecases in the manifest plugin page, in
> And, as I frequently run into walls that make me thing setuptools
> should be completely ignored, and then after fiddling about quite a
> bit, find a way around it, and then run into the next wall, etc, etc,
> etc. And these walls are getting more and more frequent... I'm
> beginning to think tha
On Mon, Apr 20, 2009 at 6:04 PM, P.J. Eby wrote:
> At 06:31 PM 4/20/2009 +0200, Lennart Regebro wrote:
>>
>> Let me reformulate that:
>>
>> > Because that's the one that generates the metadata setuptools needs to
>> > run,
>> > test itself, etc.
>>
>> Why do I need setuptools to do that? Why is no
2009/4/20 Lennart Regebro :
> At least somebody could maybe make some sort of rough plan of what
> this golden distutils should contain and how it should work, and we
> can get a feeling if it's even remotely feasible.
And, as I frequently run into walls that make me thing setuptools
should be com
On Mon, Apr 20, 2009 at 21:52, P.J. Eby wrote:
> Making a separate setup script for Python 3, at least for setuptools itself,
> if not having a general convention for that, since other packages may want
> to ship 2+3 stuff in the same package.
The typical setup script will look exactly the same u
At 09:11 PM 4/20/2009 +0200, Lennart Regebro wrote:
"Isolated"? What do you mean?
Making a separate setup script for Python 3, at least for setuptools
itself, if not having a general convention for that, since other
packages may want to ship 2+3 stuff in the same package.
Or, in the alterna
On Mon, Apr 20, 2009 at 21:01, P.J. Eby wrote:
> Look, if you want to fork setuptools to not depend on itself, knock yourself
> out. I sure can't stop you.
Well, unless somebody can come up with an alternative... But I have to
say I'm extremely reluctant to do so. And I think that my action
inst
At 07:13 PM 4/20/2009 +0200, Lennart Regebro wrote:
Which still doesn't really answer the question: Why setuptools need to
rely on setuptools.
Because there's less duplication and chances of error that
way. (Earlier versions of setuptools relied on manually-created text
files, instead of usi
On Mon, Apr 20, 2009 at 16:36, David Cournapeau
wrote:
> I agree that in the short term, distutils should be improved, but in the
> long term, I don't see anything which would be both a significant
> improvement while staying backward compatible with distutils, if only
> because so many setup.py f
On Mon, Apr 20, 2009 at 19:02, P.J. Eby wrote:
> I thought you couldn't import setuptools in setup3.py, for all the reasons
> you just described?
Yes? And then you draw some sort of conclusion of this that totally escapes me.
>> Why do I need setup.py?
>
> To define the core entry points, basica
At 06:31 PM 4/20/2009 +0200, Lennart Regebro wrote:
Let me reformulate that:
> Because that's the one that generates the metadata setuptools needs to run,
> test itself, etc.
Why do I need setuptools to do that? Why is not distutils enough?
Because distutils doesn't have an egg_info command,
At 06:30 PM 4/20/2009 +0200, Lennart Regebro wrote:
> Because that's the one that generates the metadata setuptools needs to run,
> test itself, etc.
No, setup3.py does that.
I thought you couldn't import setuptools in setup3.py, for all the
reasons you just described?
Why do I need setup.
Let me reformulate that:
> Because that's the one that generates the metadata setuptools needs to run,
> test itself, etc.
Why do I need setuptools to do that? Why is not distutils enough?
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
_
On Mon, Apr 20, 2009 at 18:17, P.J. Eby wrote:
> Because that's the one that generates the metadata setuptools needs to run,
> test itself, etc.
You really need to stop assuming everybody else here understands the
issues as well as you do, because we don't. Or well, I don't, anyway.
I don't under
At 06:02 PM 4/20/2009 +0200, Lennart Regebro wrote:
On Mon, Apr 20, 2009 at 17:07, P.J. Eby wrote:
> I still don't understand why you can't have a setup3.py that uses only
> distutils, in order to run the build2to3 on. Am I missing something?
Well, the question then becomes why not just depend
On Mon, Apr 20, 2009 at 17:07, P.J. Eby wrote:
> I still don't understand why you can't have a setup3.py that uses only
> distutils, in order to run the build2to3 on. Am I missing something?
Well, the question then becomes why not just depends on distutils all
the way? With a setup3.py that does
At 10:19 AM 4/20/2009 +0200, Lennart Regebro wrote:
I don't have a good solution to this, unless we can drop setuptools
dependency on setuptools completely, and just use plain distutils for
installing and testing setuptools.
I still don't understand why you can't have a setup3.py that uses
onl
On Mon, Apr 20, 2009 at 4:36 PM, David Cournapeau
wrote:
> Tarek Ziadé wrote:
>>
>> no it doesn't. it's a generic tool to extend a command using plugins.
>>
>
> OK.
>
>>
>> Sorry, it's too easy to say "it sucks, scratch it and re-do it" ;)
>>
>
> Yes, it is easy to say it sucks, but I am not sayi
Tarek Ziadé wrote:
>
> no it doesn't. it's a generic tool to extend a command using plugins.
>
OK.
>
> Sorry, it's too easy to say "it sucks, scratch it and re-do it" ;)
>
Yes, it is easy to say it sucks, but I am not saying that out of thin
air. Refactoring works if the general API is ok
On Mon, Apr 20, 2009 at 4:00 PM, David Cournapeau
wrote:
> Hi Tarek,
>
> Tarek Ziadé wrote:
>>
>> this can change. I am working on it. I need feedback though.
>>
>> let me know how my extension code proposal fits your needs.
>>
>> http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
>>
Hi Tarek,
Tarek Ziadé wrote:
>
> this can change. I am working on it. I need feedback though.
>
> let me know how my extension code proposal fits your needs.
>
> http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft
>
I will fill in the examples (this pages does not concern manifest
On Mon, Apr 20, 2009 at 3:23 PM, David Cournapeau
wrote:
> Paul Moore wrote:
>>
>> Are you saying that you need to use setuptools (or at least the
>> feaures of setuptools) to develop setuptools? That's crazy.To run the
>> setuptools tests, just run the test.py (or whatever) script. The
>> setupto
Paul Moore wrote:
>
> Are you saying that you need to use setuptools (or at least the
> feaures of setuptools) to develop setuptools? That's crazy.To run the
> setuptools tests, just run the test.py (or whatever) script. The
> setuptools ability to type python setup.py test, while convenient,
> sim
On Mon, Apr 20, 2009 at 14:21, Paul Moore wrote:
> Are you saying that you need to use setuptools (or at least the
> feaures of setuptools) to develop setuptools?
Currently, yes. The testsuite is run with the testrunner of
setuptools. You can run them separately too, I'm sure, but that's a
pain.
2009/4/20 Lennart Regebro :
> On Mon, Apr 20, 2009 at 11:44, Ben Finney wrote:
>> +1 for building setuptools on a base of distutils only, especially if
>> it's already been achieved.
>
> No, we are going to have to make special custom extensions, at least
> for running tests. It's not that much wo
On Mon, Apr 20, 2009 at 11:44, Ben Finney wrote:
> +1 for building setuptools on a base of distutils only, especially if
> it's already been achieved.
No, we are going to have to make special custom extensions, at least
for running tests. It's not that much work, but it is code
duplication. I don
Paul Moore writes:
> 2009/4/20 Lennart Regebro :
> > I don't have a good solution to this, unless we can drop setuptools
> > dependency on setuptools completely, and just use plain distutils
> > for installing and testing setuptools.
>
> Personally, this type of circular dependency seems totally
2009/4/20 Lennart Regebro :
> I don't have a good solution to this, unless we can drop setuptools
> dependency on setuptools completely, and just use plain distutils for
> installing and testing setuptools. This will mean no more setuptools
> source eggs, but then I don't see the purpose of those,
54 matches
Mail list logo
