David Lyon wrote:
On Thu, 08 Oct 2009 09:35:57 +0200, M.-A. Lemburg m...@egenix.com wrote:
One could say that much of the setuptools cloud came about because of
the lack of the queryable download url. Setuptools does a lot of work
here to 'work-around' the ommission on pypi of a package
Ian Bicking a écrit :
I'm coming in late and breaking threading, but wanted to reply to
Tarek's original email:
This is verifiable, stable, and to varying degrees concrete
(virtualenv being more concrete than buildout, which tends more
towards the declarative).
Is that a friday troll ?
On Fri, Oct 9, 2009 at 3:22 AM, Ian Bicking i...@colorstudy.com wrote:
I'm coming in late and breaking threading, but wanted to reply to
Tarek's original email:
- easy_install is going to be deprecated ! use Pip !
Cool! I wouldn't have written pip if I didn't think it would improve
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg m...@egenix.com wrote:
I know that the issue tracker for PyPI is (still) on SF, but
development appear to happen elsewhere and I can't find any
contact information on the PyPI web pages.
Everything is provided here:
Tarek Ziadé wrote:
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg m...@egenix.com wrote:
I know that the issue tracker for PyPI is (still) on SF, but
development appear to happen elsewhere and I can't find any
contact information on the PyPI web pages.
Everything is provided here:
Ian Bicking ianb at colorstudy.com writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned installs (which I'm not very enthusiastic
about) I'm not sure what this is?
http://pip.openplans.org/#differences-from-easy-install
If it's obsolete the
Nick Coghlan wrote:
Christian Heimes wrote:
The solution requires a new attribute in the sys module that contains
the name of the implementation. As an alternative we could use the first
field of sys.subversion but I prefer an explicit attribute. I'm
proposing sys.name with a value of
Christian Heimes lists at cheimes.de writes:
sys.vm
sys.vm(id='cpython', name='CPython', platform='C',
usersitesuffix='python26') # on win32: Python2.6
sys.vm
sys.vm(id='ironpython', name='IronPython', platform='.NET',
usersitesuffix='ironpython26) # on win32: IronPython2.6
Tarek Ziadé wrote:
I have a suggestion though, that completes Nick's answer.
distutils/command/install.py already contains install schemes and
imports USER_SITE and USER_BASE to builds user-specific install
schemes. I think it wouldn't hurt for clarity to reunite all these
schemes in a
Antoine Pitrou wrote:
`usersitesuffix` should probably be a separate sys attribute, since it doesn't
depend on the VM only, but also on the platform and version.
I don't really care and I'm happy to follow the herd in this matter. :)
Christian
___
Michael Foord wrote:
I really like this scheme. The important thing for IronPython is that we
can get it into Python 2.6 (along with other fixes to make distutils
compatible with IronPython - like not attempting to bytecode-compile
when sys.dont_write_bytecode is True).
I don't think my
Christian Heimes wrote:
Nick Coghlan wrote:
Importing yet-another-module for use in site.py doesn't sound like a
great idea, so it may make sense to migrate that information into the
sys module is this approach is taken. sys.name is a little generic
though - something more explicit like
Christian Heimes wrote:
Michael Foord wrote:
I really like this scheme. The important thing for IronPython is that we
can get it into Python 2.6 (along with other fixes to make distutils
compatible with IronPython - like not attempting to bytecode-compile
when sys.dont_write_bytecode is
M.-A. Lemburg wrote:
Christian Heimes wrote:
Nick Coghlan wrote:
Importing yet-another-module for use in site.py doesn't sound like a
great idea, so it may make sense to migrate that information into the
sys module is this approach is taken. sys.name is a little generic
though -
2009/10/9 Antoine Pitrou solip...@pitrou.net:
Ian Bicking ianb at colorstudy.com writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned installs (which I'm not very enthusiastic
about) I'm not sure what this is?
Paul Moore wrote:
2009/10/9 Antoine Pitrou solip...@pitrou.net:
Ian Bicking ianb at colorstudy.com writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned installs (which I'm not very enthusiastic
about) I'm not sure what this is?
On 5 Oct, 01:04 pm, ziade.ta...@gmail.com wrote:
On Mon, Oct 5, 2009 at 2:50 PM, s...@pobox.com wrote:
Ned Due to a change in distutils released with Python 2.6.3,
packages
Ned that use setuptools (version 0.6c9, as of this writing), or
the
� �Ned easy_install command, to build C
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their breath waiting for setuptools 0.7.
Well, if this was the BDFL pronouncement that a lot of people
On Fri, Oct 9, 2009 at 5:01 PM, Chris Withers ch...@simplistix.co.uk wrote:
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their breath waiting for
Tarek Ziadé wrote:
== The fate of setup.py, and static metadata ==
So we are going to separate the metadata description from setup.py, in
a static configuration file, that can be open and read by anyone
without
running any code.
snip
So we've worked on that lately in Distutils-SIG and came
Chris Withers chris at simplistix.co.uk writes:
Well, if this was the BDFL pronouncement that a lot of people have taken
it to be, does that allow Martin von Lewis to give the keys to
http://pypi.python.org/pypi/setuptools to the distribute developers,
so we can get on and use the
Tarek Ziadé wrote:
Some new commands are added there, when they are helpful and don't
interact with the rest. I am thinking
about upload_docs that let you upload documentation to PyPI. The
goal is to move it to Distutils
at some point, if the documentation feature of PyPI stays and starts to be
Tarek Ziadé wrote:
- The code is splitted in many packages and might be distributed under
several distributions.
- distribute.resources: that's the old pkg_resources, but
reorganized in clean, pep-8 modules. This package will
only contain the query APIs and will focus on being PEP 376
On Fri, Oct 9, 2009 at 5:32 PM, Chris Withers ch...@simplistix.co.uk wrote:
So I am adding this in Distutils for 2.7.
NB: There was no consensus on this micro-language on distutils-sig.
While I suspect I don't care as none of my packages rely on anything other
than other python packages,
Tarek Ziadé wrote:
= Virtualenv and the multiple version support in Distribute =
(I am not saying We here because this part was not discussed yet
with everyone)
Good, so maybe take this discussion to distutils-sig first?
Virtualenv allows you to create an isolated environment to install
On Fri, Oct 9, 2009 at 5:37 PM, Chris Withers ch...@simplistix.co.uk wrote:
Tarek Ziadé wrote:
Some new commands are added there, when they are helpful and don't
interact with the rest. I am thinking
about upload_docs that let you upload documentation to PyPI. The
goal is to move it to
Tarek Ziadé wrote:
How about helping the author of that extension make it work with Distribute
or just get that implementation into Distutils core instead?
It's the case. The author is a Distribute commiter and *he* has added
it in Distribute.
Great, but about just getting it into Distutils?
On Fri, Oct 9, 2009 at 5:42 PM, Chris Withers ch...@simplistix.co.uk wrote:
Tarek Ziadé wrote:
- The code is splitted in many packages and might be distributed under
several distributions.
- distribute.resources: that's the old pkg_resources...
Why not just call it pkg_resources and/or
ACTIVITY SUMMARY (10/02/09 - 10/09/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2444 open (+44) / 16471 closed (+14) / 18915 total (+58)
Open issues with patches: 976
Tarek Ziadé wrote:
- distribute.entrypoints: that's the old pkg_resources entry points
system, but on its own. it uses distribute.resources
Why not get it into the core as distutils.entrypoints? That's where it
belongs...
What do you call 'core' ? distutils.core ?
Sorry, mean stdlib.
On Fri, Oct 9, 2009 at 6:03 PM, Chris Withers ch...@simplistix.co.uk wrote:
Tarek Ziadé wrote:
How about helping the author of that extension make it work with
Distribute
or just get that implementation into Distutils core instead?
It's the case. The author is a Distribute commiter and *he*
Tarek Ziadé wrote:
This PyPI feature is pretty new. It's great to have the client command
on Distribute.
If its usage spreads it'll make it to Distutils.
If you want to see it included Distutils (I do too) help us promoting its usage
The only thing that discourages me from using the PyPI docs
On Fri, Oct 9, 2009 at 6:08 PM, Chris Withers ch...@simplistix.co.uk wrote:
Shame there hasn't been any discussion of this recently on distutils-sig...
We had many discussion on this already. I don't mind to have another
round, on the contrary,
but let's do it in Distutils-SIG
We are making a
Tarek Ziadé wrote:
NB: There was no consensus on this micro-language on distutils-sig.
While I suspect I don't care as none of my packages rely on anything other
than other python packages, others did care, and I found the syntax Tarek
was proposing pretty clumsy.
Please no bikeshedding again
On Fri, Oct 9, 2009 at 3:54 AM, kiorky kio...@cryptelium.net wrote:
If I had my way, buildout would use virtualenv and throw away its
funny script generation. If virtualenv had existed before buildout
Which one, the one provided to generate scripts from entry points with the
*.egg
recipes
Tarek Ziadé wrote:
At Python and PyPI level, 'Setuptools' is PJE's project and he's the
one that manages the list of users that have
extended rights on his project.
Indeed, if only he would see sense :-(
In Distribute, our setup.py script makes sure setuptools is not in the
way. It is
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
Tarek Ziadé wrote:
Virtualenv allows you to create an isolated environment to install
some distribution without polluting the
main site-packages, a bit like a user site-packages.
...as does buildout, and these are the right type
On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/10/9 Antoine Pitrou solip...@pitrou.net:
Ian Bicking ianb at colorstudy.com writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned installs (which I'm not very
I'm crossposting to continue on distutils.
Ian Bicking a écrit :
On Fri, Oct 9, 2009 at 3:54 AM, kiorky kio...@cryptelium.net wrote:
Well, if multi-versioned installs were deprecated, it would not be
necessary to use Setuptools' style of script generation. Instead you
could simply
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
Tarek Ziadé wrote:
Virtualenv allows you to create an isolated environment to install
some distribution without polluting the
main site-packages, a bit like a user site-packages.
...as does buildout, and
Ian Bicking wrote:
On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore p.f.mo...@gmail.com wrote:
2009/10/9 Antoine Pitrou solip...@pitrou.net:
Ian Bicking ianb at colorstudy.com writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned
Probably all these discussions are better on distutils-sig (just
copying python-dev to note the movement of the discussion)
On Fri, Oct 9, 2009 at 11:49 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
Outside of binaries on Windows, I'm still unsure if installing eggs
serves a useful
Chris Withers chris at simplistix.co.uk writes:
*sigh* I don't see it as hijacking, provided Guido is making a BDFL
pronouncement that you're maintaining this software
Well, what you are proposing *is* hijacking. PJE is not paid or employed by
Guido, he is the full author of setuptools.
On Fri, Oct 9, 2009 at 04:53, Michael Foord fuzzy...@voidspace.org.ukwrote:
Christian Heimes wrote:
Michael Foord wrote:
I really like this scheme. The important thing for IronPython is that we
can get it into Python 2.6 (along with other fixes to make distutils
compatible with IronPython
On Fri, Oct 9, 2009 at 10:57, Antoine Pitrou solip...@pitrou.net wrote:
Chris Withers chris at simplistix.co.uk writes:
*sigh* I don't see it as hijacking, provided Guido is making a BDFL
pronouncement that you're maintaining this software
Well, what you are proposing *is* hijacking. PJE
2009/10/9 Chris Withers ch...@simplistix.co.uk:
Why not get it into the core as distutils.entrypoints? That's where it
belongs...
Well, one reason is that it can't be distributed separately under that
name, and hence not be tested separately or bugfixed separately.
Rule #1 for inclusion in the
The *only* change in semantics I'm proposing is for users of
IronPython 2.6 which is not even at final release yet. CPython users
would be unaffected.
Sorry for top-posting, mobile device.
Michael
--
http://www.ironpythoninaction.com
On 9 Oct 2009, at 19:00, Brett Cannon br...@python.org
On Fri, Oct 9, 2009 at 11:32, Michael Foord fuzzy...@voidspace.org.ukwrote:
The *only* change in semantics I'm proposing is for users of IronPython 2.6
which is not even at final release yet. CPython users would be unaffected.
Then why can't IronPython patch site.py to do what they want? I
On Thu, Oct 8, 2009 at 7:17 AM, Christian Heimes li...@cheimes.de wrote:
CPython:
~/.local/lib/python2.6/site-packages
%APPDATA%/Python/Python26
IronPython:
~/.local/lib/ironpython2.6/site-packages
%APPDATA%/Python/IronPython26
Jython:
~/.local/lib/jython2.6/site-packages
On Fri, Oct 09, 2009 at 05:29:28PM +0100, Chris Withers wrote:
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
Tarek Ziadé wrote:
Virtualenv allows you to create an isolated environment to install
some distribution without polluting the
main
Chris Withers schrieb:
Tarek Ziadé wrote:
NB: There was no consensus on this micro-language on distutils-sig.
While I suspect I don't care as none of my packages rely on anything other
than other python packages, others did care, and I found the syntax Tarek
was proposing pretty clumsy.
Chris Withers schrieb:
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their breath waiting for setuptools 0.7.
Well, if this was the BDFL
On Fri, Oct 9, 2009 at 1:50 PM, Georg Brandl g.bra...@gmx.net wrote:
Chris Withers schrieb:
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their
On Fri, Oct 09, 2009 at 01:56:42PM -0700, Guido van Rossum wrote:
On Fri, Oct 9, 2009 at 1:50 PM, Georg Brandl g.bra...@gmx.net wrote:
Chris Withers schrieb:
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in
Just received:
https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error:
file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
Sorry, sent to wrong list! Please ignore.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
That's absurd. There's a certain area where Guido can make
pronouncements, but third-party packages is not it. Even if they're
hosted on python.org infrastructure.
Guido Right.
Now if you were the un-BDFL you could step in here. ;-)
This whole topic seems to have a lot of
Fellow Python developers!
In the light of our recent discussion about implementation specific
information and user site directory I like to start a new PEP. Much to
my regret I wasn't able to contribute to Python core development over
the past months. I hope I can find some free time over the
Christian wrote:
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation. Implementations may choose to
add
additional fields as they see fit. Some fields like compiler are
2009/10/9 Christian Heimes li...@cheimes.de:
Fellow Python developers!
In the light of our recent discussion about implementation specific
information and user site directory I like to start a new PEP. Much to
my regret I wasn't able to contribute to Python core development over
the past
Benjamin Peterson wrote:
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation. Implementations may choose to add
additional fields as they see fit. Some fields like compiler
I know that the issue tracker for PyPI is (still) on SF, but
development appear to happen elsewhere and I can't find any
contact information on the PyPI web pages.
PyPI discussion takes place mostly on catalog-sig.
Regards,
Martin
___
Python-Dev
2009/10/9 Christian Heimes li...@cheimes.de:
Benjamin Peterson wrote:
sys.userdirsuffix
-
Why not site.userdirsuffix?
Because all implementations of Python like to use the same, unpatched
site module. The sys module is different for every implementation. It's
more
Given that this is all about establishing some common ground between
implementations I would propose not using a CPython specific term
here such as PyStructSequence :) The Python docs seem to use structseq
for sys.float_info.
Also, why does it have to be a sequence in the first place?
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation.
I think it is important to confirm in advance that all the
implementations listed below agree to implement the PEP
Martin v. Löwis wrote:
Given that this is all about establishing some common ground between
implementations I would propose not using a CPython specific term
here such as PyStructSequence :) The Python docs seem to use structseq
for sys.float_info.
Also, why does it have to be a sequence
Martin v. Löwis wrote:
So I propose that the python.org version is identified as python.
But then we won't have a generic term for the language
itself, independent of any implementation.
The c in cpython doesn't necessarily have to refer
to the implementation language. Maybe it stands for
Martin v. Löwis wrote:
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation.
I think it is important to confirm in advance that all the
implementations listed below agree
Dino Viehland wrote:
Given that this is all about establishing some common ground between
implementations I would propose not using a CPython specific term
here such as PyStructSequence :) The Python docs seem to use structseq
for sys.float_info.
You got me! :)
compiler (required):
Christian wrote:
Martin has already answered both points to my satisfaction. Do you
agree with him?
Sure, source level makes more sense - so we'd have csc or gmcs if
compiled with Mono (assuming there's some way to do that...).
___
Python-Dev
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module
like _sys or _implementation part of the Python VM API. Then, instead
of stuffing everything into sys, we can provide this information in
modules where it belongs.
That's an interesting counter
2009/10/9 Christian Heimes li...@cheimes.de:
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module
like _sys or _implementation part of the Python VM API. Then, instead
of stuffing everything into sys, we can provide this information in
modules where it
On Fri, Oct 9, 2009 at 18:14, Benjamin Peterson benja...@python.org wrote:
2009/10/9 Christian Heimes li...@cheimes.de:
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module
like _sys or _implementation part of the Python VM API. Then, instead
of
2009/10/9 Brett Cannon br...@python.org:
But I honestly don't see why this doesn't belong in sys; it has to do with
the system environment which is the interpreter. Yes, some things currently
in sys could possibly be put elsewhere (e.g. the exception stuff could be in
'exceptions'), but I
74 matches
Mail list logo
