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
Robert Kern wrote:
On 2009-04-20 15:49, Christian Hudon wrote:
The only thing I'd need would be way to reliably determine if I'm
dealing with setuptools-based setup.py or not. I can always call "python
setup.py installl --help" and look if
--single-version-externally-managed is present in the o
On 2009-04-20 15:49, Christian Hudon wrote:
The only thing I'd need would be way to reliably determine if I'm
dealing with setuptools-based setup.py or not. I can always call "python
setup.py installl --help" and look if
--single-version-externally-managed is present in the output. Is there a
cl
P.J. Eby wrote:
At 01:28 PM 4/20/2009 -0400, Christian Hudon wrote:
Is there a way to ask setuptools to do an install that looks more
like a standard distutils install?
Yes, use "setup.py install --single-version-externally-managed
--record=/some/file". This will install the distutils way, a
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 01:28 PM 4/20/2009 -0400, Christian Hudon wrote:
Is there a way to ask setuptools to do an install that looks more
like a standard distutils install?
Yes, use "setup.py install --single-version-externally-managed
--record=/some/file". This will install the distutils way, and
record all th
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
Use --single-version-externally-managed (also pip using this flag by
default, so if you install via pip you'll get this behavior).
On Mon, Apr 20, 2009 at 12:28 PM, Christian Hudon wrote:
> Hello,
>
> We have a setup where a central /usr/local is copied to all our machines.
> The packages install
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
Hello,
We have a setup where a central /usr/local is copied to all our
machines. The packages installed in said central /usr/local are managed
via stow. (Basically, each package is installed in a separate directory
under /usr/local/stow, and invoking the stow command creates symlinks to
make
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.
Lennart Regebro wrote:
> 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. There is no test.py to run. Maybe you can use nose or something
> to run the tests, but then again you would need to port *nose* to
> P
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
David Cournapeau wrote:
> Toshio Kuratomi wrote:
>> They don't have bearing on talking about
>> redesigning how to design a new architecture that's easy to extend.
>>
>
> Those examples show why extending distutils commands with subclassing +
> post processing is not always enough. I don't unde
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
At 02:17 AM 4/20/2009 -0500, Ian Bicking wrote:
3. Namespace packages require pkg_resources?
There's a way of doing it with pkgutils, but in some way that I
don't understand, pkg_resources does it better.
pkgutil doesn't support zip files (or any other non-filename
importers/path strings),
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,
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 itself completely, and only depend on
distutils.
I have as you know ported setuptools to Python 3. I'm in the process
On Mon, Apr 20, 2009 at 09:17, Ian Bicking wrote:
> Of course if you create a project template that uses distutils, then that's
> what you'll get... just happens no one does that with paster templates.
Oh, sure, it's just lazyness from my side, nothing else.
> Entry points are the big one for me
On Sat, Apr 18, 2009 at 4:09 AM, Lennart Regebro wrote:
> Setuptools non-support for Python 3 is currently a serious hindrance
> towards Python 3 aceptance. I'm trying to figure out what to do as a
> next step in the Python 3 support for setuptools. And I have
> encountered some obstacles. The fi
44 matches
Mail list logo
