?
Regards,
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz wrote:
>
> If anyone is interested in being added as nosy for any category of
> bugs, let me know and I'll do that as I scan the tracker.
I'll take Distutils related issues,
Thank you
Tarek
___
Pyt
On Wed, Feb 11, 2009 at 12:46 AM, Stephen Thorne wrote:
> On 2009-02-10, Tarek Ziadé wrote:
>> On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz
>> wrote:
>>
>> >
>> > If anyone is interested in being added as nosy for any category of
>> >
2009/2/9 M.-A. Lemburg :
> On 2009-02-08 11:15, Tarek Ziadé wrote:
>> Hello
>>
>> To avoid confusion, as suggested by Akira who works on cleaning the
>> Distutils pages on the python.org website,
>> I would like to move http://svn.python.org/view/distutils
2009/2/17 Georg Brandl :
> Benjamin Peterson schrieb:
>> On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni wrote:
>>> Didn't a test fail because of this? seems the underlying issue is that this
>>> part of the stdlib didn't have enough test coverage. It seems that having
>>> very good/improving tes
then, if you do a checkout of
http://svn.python.org/projects/distutils/trunk it will
grab Python's Lib/distutils.
Let me know if this is not wanted. I can drop it it's no big deal.
Regards
Tarek
>
> Regards,
> Martin
>
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR |
Hello,
I am trying to reach Greg Ward to get a maintainer access to Distutils
at PyPI, but his email address at python.net (and some other) doesn't
work anymore.
Anyone knows how to reach him ?
Thanks
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programm
On Mon, Feb 23, 2009 at 6:43 PM, A.M. Kuchling wrote:
> On Mon, Feb 23, 2009 at 02:16:17PM +0100, Tarek Ziadé wrote:
>> I am trying to reach Greg Ward to get a maintainer access to Distutils
>> at PyPI, but his email address at python.net (and some other) doesn't
>>
Hello,
If no one objects, I would like to:
- put Distutils back into PEP 291 for Python 2.3 compatibility
- fix the two issues that prevent the current trunk to run with Python
2.3 to 2.5 (see http://bugs.python.org/issue5052 and the patch I
worked on)
Regards
Tarek
--
Tarek Ziadé
On Wed, Mar 25, 2009 at 1:25 PM, Antoine Pitrou wrote:
> Paul Moore gmail.com> writes:
>>
>> 3. Setuptools, unfortunately, has divided the Python distribution
>> community quite badly.
>
> Wait a little bit, and it's gonna be even worse, now that buildout and pip
> seem
> to become popular. For
On Wed, Mar 25, 2009 at 2:45 PM, Antoine Pitrou wrote:
> Tarek Ziadé gmail.com> writes:
>>
>> But I agree that the sizes of the packages are too small now, and it has gone
>> to far. Installing a web app like Plone is scary (+100 packages)
>
> I am working on a Tu
ttles. Sorry for being unclear.
Are you coming to the Summit tomorrow ? If not, I'll bring up this point.
I whish we will be able in the near future to build a team of people
from various area of
expertise, to work on these problems.
Tarek
>
> Paul.
>
--
Tarek Ziadé | As
stinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsu
No, we wil
>
> Maybe next year
> ___
> 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/ziade.tarek%40gmai
On Thu, Mar 26, 2009 at 3:29 AM, Tarek Ziadé wrote:
> On Thu, Mar 26, 2009 at 3:26 AM, Stephen J. Turnbull
> wrote:
>> Tennessee Leeuwenburg writes:
>> > GSOC?
>>
>> No. This is territory that nobody knows how to mentor yet, ya know?
>> Try it now, and
t has been said in python-dev
today but I am not sure I'll be able to read everything
before tomorrow)
Regards
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
he .egg-info directory (or file) which
has two standards today (one in Distutils, one in Setuptools) but wich should
get a common standard soon (PEP 376)
Cheers
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.word
On Thu, Mar 26, 2009 at 5:32 AM, David Cournapeau wrote:
> If distutils was split into different modules (one for the build, one
> for the compiler/platform configuration, one for the installation),
> which could be extended, tweaked, it would be much better. But the
> distutils design makes this
On Thu, Mar 26, 2009 at 2:37 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 26, 2009, at 2:31 PM, Guido van Rossum wrote:
>
>>> One thing that /would/ be helpful though is the ability to list all the
>>> resources under a specific package path. This is (I thi
e of packages"
If some kind of API + configuration file could adress this need, maybe
things could be simpler. You wouldn't fight against a central site-packages
or a per-user site-packages. You would have to explicitely provide it
Tarek
--
Tarek Ziadé | Association AfPy | www.a
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete
So we are currently working this week to flesh out this plan, and we
will send a mail to Distutils-SIG with the ouput asap.
Cheers
Tarek
--
Tarek Z
2009/3/27 P.J. Eby :
> Also, it's quite likely that platform-specific dependencies may exist as
> well. It might be possible to accommodate these things with a sufficiently
> flexible format, but currently, the only way to handle them with
> distutils/setuptools is in the setup script.
>
Yes, we
s long as Distutils let the system
packager find/change
the metadata in an easy way.
I think this is the same rationale for debian packages. Right now people tend
to use external tools like stdeb and they are OK with it (but still
gets problems
extracting stuff out of Python packages at this point)
R
On Fri, Mar 27, 2009 at 9:54 PM, Kevin Teague wrote:
>
>
> Tarek, was there any further discussion on "Requires" vs "install_requires"
> or any decisions made on what to do about this?
>
> (I've got a +1 ready for including 'install_requires' in the standard
> package metadata and marking 'Requir
ample implementation, and
> a proponent. Who's gonna bell the cat?
> ___
> 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/ziade.tarek%40gmail.com
>
--
On Fri, Apr 3, 2009 at 2:25 AM, Ben Finney wrote:
> "Phillip J. Eby" writes:
>
>> However, there's currently no standard, as far as I know, for what
>> encoding the PKG-INFO file should use.
>
> Who would define such a standard?
PEP 376 where we can explain that all files in egg-info should be i
ng about when he said we would
remove things like bdist_rpm
from the stdlib : it's too OS-specific for the stdlib to do a good job
in this area.
To discuss this plan in details, let's move to Distutils-SIG
Cheers
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR |
On Fri, Apr 3, 2009 at 6:20 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> I have taken the commitment to lead these tasks and synchronize the people
>> that are willing to help on this.
>
> Good, I'm one of those people,
Great !
> sadly my only help may
> -> I'm also skeptical that this is a good SoC project in the first place.
What is a good SoC project from your point of view ?
> -> Coming up with a wrapper for, say, Apple Keychain, could be a good
> -> project. Coming up with a unifying API for all keychains is out of
> -> scope, IMO; various
Ok what about this then: I am changing the scope a little bit, and I
think the students will be fine with this change
since it's the same work.
"The project will consist of creating a plugin system into Distutils
to be able to store and retrieve the username/password
used by some commands, without
packages because
they use this common namespace for several packages and a plain python
installation of the various packages
won't work out of the box under other systems like windows. (and for
pylint, I ended up creating my own distribution for windows...)
So :
- having namespaces natively in Python i
question is : should I make a change into the Makefile by adding
for example a variable called AR_OPTIONS
then build the ar command with AR + AR_OPTIONS
*or*
that doesn't make sense and I just need to change the behavior so it
doesn't look for AR into the Makefile. (just in os.environ)
some help on the
makefile/configure side
Even if I could mimic what's in there, I am not confident enough yet.
Please do so, by attaching your patch in the issue,
Thanks
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Pyth
On Thu, May 7, 2009 at 1:37 PM, David Cournapeau wrote:
> On Thu, May 7, 2009 at 7:07 PM, Tarek Ziadé wrote:
>> On Thu, May 7, 2009 at 11:50 AM, David Cournapeau wrote:
>>> Then, in the customize_compiler function, set archiver to $AR +
>>> $ARFLAGS. IOW, just cop
On Thu, May 7, 2009 at 2:11 PM, David Cournapeau wrote:
> But I don't know if that's easy to set up such as both python and
> numpy are built from sources.
I don't know about the numpy part, but the PyBots project code could
be a source of inspiration for the Python part
http://code.google.com/p
then
you can change it
<<< line 71
arflags=...@arflags@
<<<
ARFLAGS= cr
<<<
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
On Thu, May 7, 2009 at 11:51 PM, Eric Smith wrote:
> Tarek Ziadé wrote:
>>
>> On Thu, May 7, 2009 at 11:36 PM, Eric Smith wrote:
>>>
>>> With you ARFLAGS change, I now get the following error on a 32 bit Fedora
>>> 6
>>> box. I've done &quo
sutils.util.get_platform.
This module can be used by site.py, by distutils, and others, and will
focus on this role.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
Hello
I'm proposing this PEP, which has been discussed in Distutils-SIG, for
inclusion in Python 2.7 and 3.2
http://www.python.org/dev/peps/pep-0376/
Please comment !
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Pytho
2009/5/15 P.J. Eby :
> At 12:21 AM 5/15/2009 +0200, Tarek Ziadé wrote:
>>
>> Hello
>>
>> I'm proposing this PEP, which has been discussed in Distutils-SIG, for
>> inclusion in Python 2.7 and 3.2
>>
>> http://www.python.org/dev/peps/pep-0376/
&
ortant part of both
> generating and parsing .egg-info filenemaes. At minimum, the relevant
> setuptools docs that define these standards should be cited.
I need to find back your comments for this part, I must have missed
them. That's
the last part I didn't work out yet on
that this is actually something we have
> to worry about, though.
>
> Cheers,
>
> Dirkjan
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http
[3] http://www.unisys.com/about__unisys/lzw
--
Tarek Ziadé | http://ziade.org
___
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
Ok thanks for all the feedback, I'll remove compress support
Tarek
On Mon, May 18, 2009 at 10:06 AM, Nick Craig-Wood wrote:
> Michael Foord wrote:
>> Antoine Pitrou wrote:
>> > Tarek Ziadé gmail.com> writes:
>> >
>> >> But I was wonderi
them, the EggFormats doc explains how these file/dir
> structures are currently laid out by setuptools, easy_install, pip, etc.,
> and the PEP should probably reference that.
work in progress
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev
On Tue, May 19, 2009 at 4:03 PM, Antoine Pitrou wrote:
> Ronald Oussoren mac.com> writes:
>>
>> Wouldn't it be possible to use a CSV file for this? That way we
>> wouldn't have to invent yet another escaping mechanism and there's
>> already good suppport for reading and writing CSV files in the
>
ut at
this stage I am unable
to work them on the paper, without having a prototype to try things out.
So I guess I'll start this prototype in bitbucket and come back with
it for feedback
in Distutils-SIG, for a new PEP 376 round.
Tarek
--
Tarek Ziadé | http://ziade.org
___
-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com
>
>
--
Tarek Ziadé | http://ziade.org
___
Python
On Wed, May 20, 2009 at 11:48 AM, Tarek Ziadé wrote:
> So I guess I'll start this prototype in bitbucket and come back with it for
> feedback
> in Distutils-SIG, for a new PEP 376 round.
Ok so FYI, I moved the discussion here:
http://mail.python.org/pipermail/distutils-sig/2009-M
m to be
too old to run, they should be upgraded
- ppc Debian unstable trunk keeps on failing to connect to svn.python.org
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/
On Fri, May 29, 2009 at 12:39 AM, David Bolen wrote:
> David Bolen writes:
>
>> Ooops, that's mine. Geez - it's a VM, but has a 10GB C: drive, and
>> the actual build slave has its working directory on a separate virtual
>> drive. Wonder what the heck has filled up the system drive. I'm
>> wor
beta-testers that are willing to switch to
this new version to test it extensively before
2.7/3.2 are out.
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On Mon, Jun 22, 2009 at 4:59 PM, Antoine Pitrou wrote:
> - the **MD5** hash of the file, encoded in hex. Notice that `pyc` and
> `pyo`
>generated files will not have a hash.
>
> Why the exception for pyc and pyo files?
As in PEP 262, since they are produced automatically from a py file,
c
2009/6/22 P.J. Eby :
> At 05:42 PM 6/22/2009 +0200, Tarek Ziadé wrote:
>>
>> Wouldn't it be better to use the native line terminator on the current
>> platform? (someone might want to edit or at least view the file)
>>
>>
>> Good idea, I'll change
On Tue, Jun 23, 2009 at 3:41 AM, Kevin Teague wrote:
>>
>>
>> A plural class name looks strange (I think it's the first time I see one
>> in
>> the CPython codebase). How about another name? (DistributionPool,
>> DistributionMap, WorkingSet etc.).
>>
>> Sure, WorkingSet is nice, it's the name used
On Wed, Jun 24, 2009 at 11:18 AM, Antoine Pitrou wrote:
> Sridhar Ratnakumar activestate.com> writes:
>>
>> On 09-06-23 02:57 AM, Nick Coghlan wrote:
>> > Something like DistributionDirectoryMap should cover it.
>> >
>> > You could probably get away with shortening "Directory" to "Dir" in the
>> >
he inclusion of fields like
"installed_requires" (dependencies)
- PEP 386, that talks about distribution version numbers (because it's
needed to describe dependencies)
While they are still under heavy discussion, I have good hope that
they will both make it for 2.7 and 3.2.
Regards
liminate the need for
> him to actually *say* that he is approving the PEP on that basis.
Sure, I didn't want to bypass the process, I was not really sure about
the right move on this PEP
since it was based on the summit decisions,
I'll wait for Guido decision, thanks.
Cheers
Tarek
a lot on the topic and I am trying to get key players
involved in this, like os packagers etc.
We've built this PEP in respect with existing tools like setuptools,
etc, and I am sending mails at python-dev
to make sure evereyone involved in python development
It can be
> as minimalist as you like, but I'd like to see it present.
it's already there:
http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function
Regards
Tarek
--
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
2009/6/30 P.J. Eby :
> At 07:57 PM 6/29/2009 +0200, Tarek Ziadé wrote:
>>
>> Hello,
>>
>> If no one objects, I'd like to push PEP 376 in the "accepted" status
>> and go ahead with its implementation,
>> with continuous feedback at Distutils-SIG
On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano wrote:
> On Wed, 1 Jul 2009 05:19:07 am Tarek Ziadé wrote:
>> 2009/6/30 Guido van Rossum :
> ...
>> > So what *is* the distutils-sig consensus?
>>
>> The consensus is to have one and only one way to install
&g
On Tue, Jun 30, 2009 at 10:06 PM, Scott David
Daniels wrote:
> Tarek Ziadé wrote:
>>
>> On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore wrote:
>>>
>>> [1] I'd actually like it if the PEP defined an uninstall command -
>>> something like "python -
On Tue, Jun 30, 2009 at 11:11 PM, Nick Coghlan wrote:
>>
>>
>> previous formats will not be supported but that won't break anything
>> of course since the new APIs will work only over the distribution
>> installed with the new version of distutils.
>
> To address PJE's question in the PEP, it may b
On Tue, Jun 30, 2009 at 10:11 PM, Paul Moore wrote:
>> We said during the summit at Pycon that we wanted this feature in
>> Distutils, (Guido said so)
>
> "We" in this context denotes the people at the summit. Please remember
> that people who weren't there still have an opinion - and it may well
>
2009/7/1 P.J. Eby :
> At 01:34 AM 7/1/2009 +0200, Tarek Ziadé wrote:
>>
>> On Wed, Jul 1, 2009 at 12:47 AM, Steven D'Aprano
>> wrote:
>> > I don't see how this proposal will help in the second case. If you
>> > install distribution Spam, containing
On Wed, Jul 1, 2009 at 2:27 PM, Nick Coghlan wrote:
> However, having uninstall as a command supported by setup.py also makes
> a certain amount of sense.
>
Yes, that could be an alias that just calls the uninstall global
function using the distribution
name.
__
On Wed, Jul 1, 2009 at 10:35 AM, Paul Moore wrote:
> 2009/7/1 Tarek Ziadé :
>>> That (at least as I read it) is a function, not a command.
>>> If it is a command, give an example of its use from the command line
>>> for us poor "don't want to r
en though distutils is a
> mess of undocumented functionality, I don't think that you can base
> new work on undocumented internals - you should document them first,
> or things will never get any better :-()
>
> Paul.
>
--
Tarek Ziadé | http://ziade.org
On Wed, Jul 1, 2009 at 1:44 PM, Paul Moore wrote:
> "The problem is that many people use easy_install or pip to install
> their packages..."
>
> As already noted by others, it's not clear why this is a problem. But
> worse is the fact that the paragraph reads to me as saying that
> easy_install/pip
On Wed, Jul 1, 2009 at 10:20 AM, Michael Foord wrote:
>>
>> Uninstall as a command feels a little weird. Since "python setup.py
>> [some-command]" implies that the setup.py contains information about the
>> distribution that the command is being applied to. So instead of:
>>
>> $ python setup.py un
On Thu, Jul 2, 2009 at 4:41 AM, P.J. Eby wrote:
> Yes and no. Not providing uninstall support is reasonable, but the PEP also
> has features to query packages in general.
>
> (There's also no technical reason why comparable manifest and uninstall
> support can't be provided for .egg files and dire
On Thu, Jul 2, 2009 at 5:44 AM, Stephen J. Turnbull wrote:
> That's a judgment you must make. However, Paul's opinion seems to be
> that it is internal, and not needed by third-parties who are working
> "on the top" of these classes. If upon consideration you agree, you
> should take those "detai
On Thu, Jul 2, 2009 at 1:32 PM, Nick Coghlan wrote:
>>
>> Yes exactly, I was going to add:
>>
>> $ python -m distutils.uninstall some_package
>
> A directly executable submodule is an even better idea than making
> distutils itself executable. Definitely worth mentioning in the PEP in
> the section
On Wed, Jul 1, 2009 at 1:44 PM, Paul Moore wrote:
> "Adding a RECORD file"
>
> You say "at installation time" - please clarify. Do you only mean
> setup.py install? What about bdist_wininst and bdist_msi? What about
> third party bdist style tools? How will they ensure they get a RECORD
> file?
>
>
On Thu, Jul 2, 2009 at 2:39 PM, Paul Moore wrote:
> 2009/7/2 Tarek Ziadé :
>> For absolute paths now that gets installed, what would be the
>> difference between the pre-generated
>> RECORD file and the RECORD file installed on the win32 target system, if any
>> ?
&
On Thu, Jul 2, 2009 at 4:35 PM, Paul Moore wrote:
> Ta. I'll give it a go tonight. But haven't you made the point yourself
> by saying I'll need to change the directory? This will fail for me as
> I don't have a "/tmp" directory. So I'd expect a bdist installer
> (*any* bdist installer) to fail, as
2009/7/3 Paul Moore :
> This is a good point. Distutils only installs files in the filesystem
> - it has no facilities for installing packages based on any other sort
> of PEP 302 based importers. Hence, PEP 376 in principle should only
> relate to filesystem-based distributions. But it also mentio
On Fri, Jul 3, 2009 at 4:28 PM, Nick Coghlan wrote:
> I will note (and I believe this is also the main point that Lukasz was
> making) that having the distribution metadata outside the distribution
> as currently proposed in PEP 376 is going to make any eventual PEP 302
> integration much harder -
2009/7/3 Paul Moore :
> Does this sound sensible? Tarek, would you be OK with me attempting to
> modify your prototype to support this protocol? Are there any tests
> for PEP 376, so that I can confirm I haven't completely broken
> something? If I can, I'll knock up some simple prototype importers
On Fri, Jul 3, 2009 at 7:02 PM, P.J. Eby wrote:
> At 02:54 PM 7/3/2009 +0100, Paul Moore wrote:
>>
>> Eggs are fundamentally a PEP 302 zip file format. There are some extra
>> bits of metadata for setuptools/easy_install in there (as I understand
>> things) but essentially they are zip files. When
2009/7/4 Paul Moore :
> 2009/7/4 Paul Moore :
>> 2009/7/3 Tarek Ziadé :
>>> You can give me a bitbucket account so I can give you write access to the
>>> repo,
>>> There are tests as long as you install Nose.
>>
>> How do I get the tests to work? Ju
On Sat, Jul 4, 2009 at 3:04 PM, Paul Moore wrote:
> 2009/7/3 Tarek Ziadé :
>> 2009/7/3 Paul Moore :
>>> Does this sound sensible? Tarek, would you be OK with me attempting to
>>> modify your prototype to support this protocol? Are there any tests
>>> for PEP
2009/7/4 Brett Cannon :
>>
>> P.S. +lots on using 'metadata' in the PEP 376 method names rather than
>> the jargon 'egginfo'. Jargon isn't always bad, but using it seems fairly
>> gratuitous in this case.
>
> Ditto from here. Plus I have an aversion to terminology that goes down the
> reptile route
On Sun, Jul 5, 2009 at 3:13 PM, Paul Moore wrote:
> 2009/7/5 Tarek Ziadé :
>> Go for it please, and let me know if you set a bitbucket account, so
>> you can push your commits in there directly
>
> My bitbucket account is
ves are in the filesystem,
having a sqlite db to
index the list of installed distributions makes a good cache solution
to reduce the disk I/O
and speed up the query functions.
So maybe we could use a disk-based cache for site-packages-like
directories in the
form of a sqlite db. That's w
2009/7/5 Paul Moore :
> The PEP says:
>
> """
> get_egginfo_files(local=False) -> iterator of paths
>
> Iterates over the RECORD entries and return paths for each line if the
> path is pointing a file located in the .egg-info directory or one of
> its subdirectory.
> """
>
> Should this method real
use it's not handling
> case-insensitivity or name canonicalization. (I've mentioned these issue
> previously on the distutils-sig.)
Yes thanks, we need to fix that, the case-insensitivity or name
canonicalization functions are present, just to be used
in
2009/7/5 P.J. Eby :
> At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>
>> The loader would still work with "DIST_NAME.egg-info" directories for
>> compatibility with
>> existing format in the query APIs, but the Distutils install command
>> would rather
orrect; they will get confused because they will think that the
> relevant package is *not* installed, and proceed to install a duplicate.
> That's why .egg-info was added to the stdlib in the first place.
>
>
--
Tarek Ziadé | http://ziade.org
_
2009/7/6 Paul Moore :
> 2009/7/6 P.J. Eby :
>> At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
>>>
>>> But if it's based on PEP 302 protocols and if the pkgutil code works
>>> with the sys.meta_path hook,
>>> setuptools could then provide it
2009/7/6 Ronald Oussoren :
> I'm -1 on changing the name. For better or worse setuptools is the elephant
> in the room w.r.t. package management and it would IMHO be better to stay
> compatible (even if the stdlib only implements a subset of
> setuptools/pkg_resources)
>
I'd rather see the elephan
On Mon, Jul 6, 2009 at 5:14 PM, Paul Moore wrote:
> [...]
> And yet, given that PEP 376 is explicitly being designed with a goal
> being to act as the common standard that *all* package management
> formats can use, is it not the whole point that once it's defined and
> we have achieved consensus,
On Mon, Jul 6, 2009 at 5:53 PM, Paul Moore wrote:
> 2009/7/6 Tarek Ziadé :
>> why can't we just go ahead and continue the work as we started with PEP 376,
>> introducing your work on PEP 302-like behavior.
>>
>> Then if we get a consensus on this PEP and introduce i
On Mon, Jul 6, 2009 at 6:58 PM, P.J. Eby wrote:
>> My site-packages has a confusing mix of egginfo directories and files.
>> Note that I NEVER use setuptools other than where an existing
>> package's setup.py requires it. In that case, I still only do python
>> setup.py bdist_wininst and install th
On Tue, Jul 7, 2009 at 12:16 AM, Paul Moore wrote:
>>
>> I believe the idea of having different names in 2.x and 3.x would likely
>> cause too many problems for simple bdist_* installers of modules that
>> use only the common 2.x/3.x language subset, so I'm also -1 on that idea.
>
> That suits me t
2009/7/7 Paul Moore :
> 2009/7/6 P.J. Eby :
>> At 07:38 PM 7/6/2009 +0100, Paul Moore wrote:
>>>
>>> As promised, here are some open questions on PEP 376.
>>>
>>> - Will the public API names be changed from *egginfo* to *metadata*?
>>
>> +1 (FWIW, 'metadata' is what pkg_resources API refers to this
2009/7/7 Paul Moore :
> 2009/7/6 Nick Coghlan :
>> I'd add one more question to the list: is allowing backslash separated
>> names in the RECORD file actually a good idea, or would it be better to
>> always use forward slashes?
>
> They do always use forward slashes.
>
>> For the other questions, I
On Tue, Jul 7, 2009 at 10:33 AM, Paul Moore wrote:
> 2009/7/7 Tarek Ziadé :
>> Unless we define a "drive that contains the python installation" maybe, or
>> the "Program Files" directory
>>
>> would that make sense from a win32 point of view ?
On Tue, Jul 7, 2009 at 11:28 AM, M.-A. Lemburg wrote:
>
> Writing an uninstall command really isn't all that hard, provided
> you stick with the standard distutils "python setup.py install"
> dance. The whole packaging approach only complicates things, IMHO.
You can't expect people to keep the dis
1 - 100 of 475 matches
Mail list logo
