Forgive me if this isn't the correct venue for this question and I ask your
help directing me to the correct place if it is not.
In PEP-376 it states with respect to the valid hashes in a Wheel RECORD file:
"The hash is either the empty string or the hash algorithm as named in
hashlib.algorithm
Hi Paul,
> Looking at a RECORD file installed by pysetup (on 3.3 trunk, on
> Windows) all of the filenames seem to be absolute, even though the
> package is pure-Python and so everything is under site-packages.
> Looking at PEP 376, it looks like the paths should be relative to
> site-packages. Tw
Looking at a RECORD file installed by pysetup (on 3.3 trunk, on
Windows) all of the filenames seem to be absolute, even though the
package is pure-Python and so everything is under site-packages.
Looking at PEP 376, it looks like the paths should be relative to
site-packages. Two questions:
1. Am
Hello
Le 03/08/2010 13:09, Michael Foord a écrit :
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
> [idea about sqlite3 db for caching]
[distros won’t like it, the filesystem is the db]
>>> [the db is a cache, it does no
On 8/3/2010 12:33 PM, Glyph Lefkowitz wrote:
>
> On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
>
>> I don't think that's a problem: the SQLite database would be a cache
>> like e.g. a font cache or TCSH command cache, not a replacement of
>> the meta files stored in directories.
>>
>> Such a d
On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote:
> I don't think that's a problem: the SQLite database would be a cache
> like e.g. a font cache or TCSH command cache, not a replacement of
> the meta files stored in directories.
>
> Such a database would solve many things at once: faster access
On 03/08/2010 16:24, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
wrote:
On 03/08/2010 15:19, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
wrote:
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg"wrote:
On Tue, Aug 3, 2010 at 11:35 PM, Michael Foord
wrote:
> On 03/08/2010 15:19, David Cournapeau wrote:
>>
>> On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou
>> wrote:
>>
>>>
>>> On Tue, 03 Aug 2010 10:28:07 +0200
>>> "M.-A. Lemburg" wrote:
>>>
>
> Don't forget system packaging tools like .d
At 01:40 PM 8/3/2010 +0200, M.-A. Lemburg wrote:
If you look at the proposal, it is really just about adding a
new data store to manage a certain package type called "plugins".
Next time around, someone will want to see support for "skins" or
"themes". Then perhaps identify "script" packages, or
On 03/08/2010 15:19, David Cournapeau wrote:
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote:
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg" wrote:
Don't forget system packaging tools like .deb, .rpm, etc., which do not
generally take kindly to updating such things. For be
At 10:28 AM 8/3/2010 +0200, M.-A. Lemburg wrote:
Since you are into comparing numbers, you might want to count
the number of Zope plugins that are available on PyPI and its plugin
system has been around much longer than setuptools has been.
I don't think that proves anything, though.
Actually,
> There is a tension between the two approaches: either you want
> "auto-discovery", or you want a system with explicit registration and
> only the registered plugins would be visible to the system.
I think both are necessary. A discovery API should be available, but the
library or application sh
On Tue, Aug 3, 2010 at 8:48 PM, Antoine Pitrou wrote:
> On Tue, 03 Aug 2010 10:28:07 +0200
> "M.-A. Lemburg" wrote:
>> >
>> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
>> > generally take kindly to updating such things. For better or worse, the
>> > filesystem *is*
On 2 Aug, 2010, at 2:03, Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord
> wrote:
>> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>>
>>> [snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied
API
for activation.
>>>
>>> But
On Tue, 03 Aug 2010 10:28:07 +0200
"M.-A. Lemburg" wrote:
> >
> > Don't forget system packaging tools like .deb, .rpm, etc., which do not
> > generally take kindly to updating such things. For better or worse, the
> > filesystem *is* our "central database" these days.
>
> I don't think that's a
Michael Foord wrote:
> On 03/08/2010 09:28, M.-A. Lemburg wrote:
>> P.J. Eby wrote:
>>
>>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>>>
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O
On 03/08/2010 09:28, M.-A. Lemburg wrote:
P.J. Eby wrote:
At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other packa
P.J. Eby wrote:
> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
>> If that's the case, then it would be better to come up with an
>> idea of how to make access to that meta-data available in a less
>> I/O intense way, e.g. by having pip or other package managers update
>> a central SQLite databa
Éric Araujo wrote:
>> What you might want to do is add new type fields to PEP 345,
>> making it easier to identify and list packages that work as
>> plugins for applications, e.g.
>>
>> Type: Plugin for MyCoolApp
>>
>> The MyCoolApp could then use the Type-field to identify all
>> installed plugins
> What you might want to do is add new type fields to PEP 345,
> making it easier to identify and list packages that work as
> plugins for applications, e.g.
>
> Type: Plugin for MyCoolApp
>
> The MyCoolApp could then use the Type-field to identify all
> installed plugins, get their installation
At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote:
If that's the case, then it would be better to come up with an
idea of how to make access to that meta-data available in a less
I/O intense way, e.g. by having pip or other package managers update
a central SQLite database cache of the data found o
At 09:03 PM 8/2/2010 +0100, Michael Foord wrote:
Ouch. I really don't want to emulate that system. For installing a
plugin for a single project the recommended technique is:
* Unpack the source. It should provide a setup.py.
* Run:
$ python setup.py bdist_egg
Then you wil
At 05:08 PM 8/2/2010 +0200, Ãric Araujo wrote:
I wonder if functions in pkgutil or importlib could allow one to
iterate over the plugins (i.e. submodules and subpackages of the
namespace package) without actually loading then.
See pkgutil.walk_packages(), available since 2.5.
It has to load
Michael Foord wrote:
> On 02/08/2010 20:36, M.-A. Lemburg wrote:
>> Michael Foord wrote:
>>
>>> On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
>>>
On 12:21 pm, m...@egenix.com wrote:
> Tarek Ziad� wrote:
>
>> On Mon, Aug 2, 2010 at 3:06 AM, P.J.
On 02/08/2010 20:36, M.-A. Lemburg wrote:
Michael Foord wrote:
On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
So without specific examples
Michael Foord wrote:
> On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
>> On 12:21 pm, m...@egenix.com wrote:
>>> Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
>
> So without specific examples of why this is a problem, it's hard to
> see why
On Mon, Aug 2, 2010 at 8:48 PM, Michael Foord wrote:
> On 02/08/2010 19:45, Holger Krekel wrote:
[...]
I'd much prefer a one-step process and rather provide a way to not-use
a plugin even if installed. The difference is e.g. with py.test that i
can point users to e.g.
p
On 02/08/2010 19:45, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord wrote:
On 02/08/2010 19:05, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bickingwrote:
Just to add a general opinion in here:
Having worked with Setuptools' entry points
On Mon, Aug 2, 2010 at 8:12 PM, Michael Foord wrote:
> On 02/08/2010 19:05, Holger Krekel wrote:
>>
>> On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
>>
>>>
>>> Just to add a general opinion in here:
>>>
>>> Having worked with Setuptools' entry points, and a little with some Zope
>>> pluginis
On 02/08/2010 19:05, Holger Krekel wrote:
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
Just to add a general opinion in here:
Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways Z
On Mon, Aug 2, 2010 at 6:57 PM, Ian Bicking wrote:
> Just to add a general opinion in here:
>
> Having worked with Setuptools' entry points, and a little with some Zope
> pluginish systems (Products.*, which I don't think anyone liked much, and
> some ways ZCML is used is pluginish), I'm not very
Just to add a general opinion in here:
Having worked with Setuptools' entry points, and a little with some Zope
pluginish systems (Products.*, which I don't think anyone liked much, and
some ways ZCML is used is pluginish), I'm not very excited about these. The
plugin system that causes the least
At 01:10 PM 8/2/2010 +0200, Tarek Ziadé wrote:
I don't have a specific example in mind, and I must admit that if an
application does the right thing
(provide the right configuration file), this activate feature is not
useful at all. So it seems to be a bad idea.
Well, it's not a *bad* idea as s
At 01:53 PM 8/2/2010 +, exar...@twistedmatrix.com wrote:
On 01:27 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
This is also roughly how Twisted's plugin system works. One drawback,
though, is that it means potentially executing a large amount of Python
in order to load plugi
On 03:08 pm, mer...@netwok.org wrote:
Le 02/08/2010 14:31, exar...@twistedmatrix.com a �crit :
On 12:21 pm, m...@egenix.com wrote:
Do we really need to make Python packaging even more complicated by
adding support for application-specific plugin mechanisms ?
Packages can already work as applic
On Aug 2, 2010, at 9:53 AM, exar...@twistedmatrix.com wrote:
> On 01:27 pm, m...@egenix.com wrote:
>> exar...@twistedmatrix.com wrote:
>>> On 12:21 pm, m...@egenix.com wrote:
See Zope for an example of how well this simply mechanism works out in
practice: it simply scans the "Prod
Le 02/08/2010 14:31, exar...@twistedmatrix.com a écrit :
> On 12:21 pm, m...@egenix.com wrote:
>> Do we really need to make Python packaging even more complicated by
>> adding support for application-specific plugin mechanisms ?
>>
>> Packages can already work as application plugins by simply defin
On 01:27 pm, m...@egenix.com wrote:
exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
See Zope for an example of how well this simply mechanism works out
in
practice: it simply scans the "Products" namespace for sub-packages
and
then loads each sub-package it finds to hav
exar...@twistedmatrix.com wrote:
> On 12:21 pm, m...@egenix.com wrote:
>> Tarek Ziad� wrote:
>>> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
>>> ..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration fil
On 02/08/2010 13:31, exar...@twistedmatrix.com wrote:
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration files is
On 12:21 pm, m...@egenix.com wrote:
Tarek Ziad� wrote:
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby
wrote:
..
So without specific examples of why this is a problem, it's hard to
see why
a special Python-specific set of configuration files is needed to
resolve
it, vs. say, encouraging applicat
Tarek Ziadé wrote:
> On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
> ..
>>
>> So without specific examples of why this is a problem, it's hard to see why
>> a special Python-specific set of configuration files is needed to resolve
>> it, vs. say, encouraging application authors to use the availa
> The PLUGINS file can be kept only for the state value, which is not read-only.
It will be for OS packages.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.o
On Mon, Aug 2, 2010 at 3:06 AM, P.J. Eby wrote:
..
>
> So without specific examples of why this is a problem, it's hard to see why
> a special Python-specific set of configuration files is needed to resolve
> it, vs. say, encouraging application authors to use the available
> alternatives for doin
On Sun, Aug 1, 2010 at 10:37 PM, Tarek Ziadé wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> =
At 02:03 AM 8/2/2010 +0200, Tarek Ziadé wrote:
but then we would be back to the problem mentioned about entry points:
installing projects can implicitly add a plugin and activate it, and break
existing applications that iterate over entry points without further
configuration. So being able to dis
On 02/08/2010 01:03, Tarek Ziadé wrote:
On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord wrote:
On 02/08/2010 00:46, Tarek Ziadé wrote:
[snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied
API
for activation.
But the discovery API you w
On Mon, Aug 2, 2010 at 1:56 AM, Michael Foord wrote:
> On 02/08/2010 00:46, Tarek Ziadé wrote:
>>
>> [snip...]
>>>
>>> I don't think that unittest would use a distutils2 (or pkgutil) supplied
>>> API
>>> for activation.
>>>
>>
>> But the discovery API you will use might just simply filter out
>> d
On 02/08/2010 00:46, Tarek Ziadé wrote:
[snip...]
I don't think that unittest would use a distutils2 (or pkgutil) supplied API
for activation.
But the discovery API you will use might just simply filter out
disabled plugins.
I did consider asking this but thought it was a silly ques
On Mon, Aug 2, 2010 at 1:11 AM, Michael Foord wrote:
> This seems fine; I mean it isn't written directly by humans or intended to
> be read directly by humans I guess. :-)
>
> (Users will specify plugins in the setup metadata and this will be written
> on install by distutils2 - right?.)
Yes, exa
On 01/08/2010 21:37, Tarek Ziadé wrote:
Hello,
Here's a proposal to extend PEP 376 to support a basic plugins feature
-- you should read PEP 376 before reading this mail
It's basically Phillip's entry points, but with an activation flag,
and a per-user config file.
= adding a PLUGINS file =
A
On Sun, Aug 1, 2010 at 11:55 PM, Nick Coghlan wrote:
...
> Is dealing with name conflicts left up to the application?
When an application iterates on the plugins that are supposely built
for it, it will probably expect a single type of object. For instance
unitest2 will want classes that are over
On Mon, Aug 2, 2010 at 6:37 AM, Tarek Ziadé wrote:
> Hello,
>
> Here's a proposal to extend PEP 376 to support a basic plugins feature
> -- you should read PEP 376 before reading this mail
>
> It's basically Phillip's entry points, but with an activation flag,
> and a per-user config file.
>
> = a
Hello,
Here's a proposal to extend PEP 376 to support a basic plugins feature
-- you should read PEP 376 before reading this mail
It's basically Phillip's entry points, but with an activation flag,
and a per-user config file.
= adding a PLUGINS file =
A new file called 'PLUGINS' is added to the
On Thu, Apr 22, 2010 at 6:05 PM, Tarek Ziadé wrote:
> 2010/4/22 P.J. Eby :
>> At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote:
>>>
>>> Hello,
>>>
>>> I think I went through all the latest feedback regarding PEP 376.
>>>
>>> There will be still some work of course, on the implementation side
>>> (fo
2010/4/22 P.J. Eby :
> At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote:
>>
>> Hello,
>>
>> I think I went through all the latest feedback regarding PEP 376.
>>
>> There will be still some work of course, on the implementation side
>> (for instance the Zip issues described by PJE).
>>
>> But I would
At 10:54 AM 4/22/2010 +0200, Tarek Ziadé wrote:
Hello,
I think I went through all the latest feedback regarding PEP 376.
There will be still some work of course, on the implementation side
(for instance the Zip issues described by PJE).
But I would like to go ahead and propose PEP 376 for acce
2010/4/22 Eric Smith :
> Jeroen Ruigrok van der Werven wrote:
>>
>> -On [20100422 10:55], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
>>>
>>> The next big piece is the FHS-compatible handling of resource files,
>>> which will worth a PEP on its own.
>>
>> You do realize, I hope, that FHS is only fol
Jeroen Ruigrok van der Werven wrote:
-On [20100422 10:55], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
The next big piece is the FHS-compatible handling of resource files,
which will worth a PEP on its own.
You do realize, I hope, that FHS is only followed by Linux distributions and
not even fu
-On [20100422 10:55], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
>The next big piece is the FHS-compatible handling of resource files,
>which will worth a PEP on its own.
You do realize, I hope, that FHS is only followed by Linux distributions and
not even fully at that. BSD Unixes, for example, h
Hello,
I think I went through all the latest feedback regarding PEP 376.
There will be still some work of course, on the implementation side
(for instance the Zip issues described by PJE).
But I would like to go ahead and propose PEP 376 for acceptance.
If it's accepted, I will implement it in
2009/7/15 Sridhar Ratnakumar :
> On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé
> wrote:
>
get_installed_files(local=False) -> iterator of (path, md5, size)
>>>
>>> Will this also return the directories /created/ during the installation?
>>> For example, will it also contain the entry "docut
On Wed, 15 Jul 2009 13:47:35 -0400, Chris McDonough
wrote:
> I've been trying to follow this discussion now for weeks. The signal to
> noise ratio is pretty low.
I'm -1 on that..
As a relative newcomer to python packaging I'm finding all these
discussions very informative. :-)
> I'd love to hav
Tarek Ziadé wrote:
In any case I don't see any use case to have a "site-packages"
remaining in Python itself.
I have and am using it. Where else would you have me put library
packages meant to be accessible by any Python program?
Terry Jan Reedy
___
On Wed, 15 Jul 2009 02:01:24 -0700, Tarek Ziadé
wrote:
get_installed_files(local=False) -> iterator of (path, md5, size)
Will this also return the directories /created/ during the installation?
For example, will it also contain the entry "docutils" .. along with
"docutils/__init__.py"?
I
On Tue, Jul 14, 2009 at 2:12 AM, Sridhar
Ratnakumar wrote:
> Here are my comments regarding PEP 376 with respect to PyPM (the Python
> package manager being developd at ActiveState)
>
>
> Multiple versions: I understand that the PEP does not support
> installation (thus uninstallation) of multiple
--
http://www.ironpythoninaction.com
On 14 Jul 2009, at 01:12, "Sridhar Ratnakumar"
wrote:
Here are my comments regarding PEP 376 with respect to PyPM (the
Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support
installation
Here are my comments regarding PEP 376 with respect to PyPM (the Python
package manager being developd at ActiveState)
Multiple versions: I understand that the PEP does not support
installation (thus uninstallation) of multiple versions of the same
package. Should this be explicitly mentioned in
On Thu, 09 Jul 2009 01:22:19 -0700, Tarek Ziadé
wrote:
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumar wrote:
Other than easy_install/pip, there is also PyPM which is being
developed at
ActiveState. PyPM is the Python package manager much like what ppm is
for
ActivePerl.
Great ! be
On Fri, 10 Jul 2009 01:56:36 -0700, Paul Moore wrote:
One thing that did occur to me based on this - do we want the format to
support designation of files (such as config files) that *shouldn't* be
uninstalled along with everything else? Or are we happy with not
mentioning the file in RECORD at
2009/7/9 Nick Coghlan :
> Paul Moore wrote:
>> - some cases are not simple, and it's not clear to me how useful
>> "nearly always accurate" data will be
>
> Since the accuracy can always be checked against the filesystem, I think
> the metadata is useful even if not 100% reliable. Applications that
Paul Moore wrote:
> - some cases are not simple, and it's not clear to me how useful
> "nearly always accurate" data will be
Since the accuracy can always be checked against the filesystem, I think
the metadata is useful even if not 100% reliable. Applications that need
the extra assurance (such a
2009/7/9 Eric Smith :
> Yes. I'm just trying to point out that the information in the PEP is
> applicable only to the set of installers that want to work together in some
> integrated way. It doesn't apply to all installers, and I think that's the
> bigger problem.
Interoperability standards are o
P.J. Eby wrote:
At 11:20 PM 7/8/2009 -0400, Eric Smith wrote:
P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
Or uninstall where the installer is "setup.py install", actually.
I think we need to move away from "setup.py install". It
2009/7/9 Paul Moore :
> I'd like to add a test case using a non-standard PEP 302 importer, but
> that's a small detail.
I've just pushed a PEP 302 importer test case.
The level of boilerplate needed is a bit painful, but it's fine as a
prototype. When we get consensus on some of the remaining det
On Thu, Jul 9, 2009 at 4:18 PM, Paul Moore wrote:
>>
>> There might be a library (and I call dibs on the name "distlib" :) that
>> provides support routines to parse setup.info, but there's no framework
>> involved. And no need for a plugin system.
>
> +1. Now who's going to design & write it?
I
Eric Smith wrote:
> I really don't get this use case of multiple installers trying to
> install the same package. There's just no way that running "yum install
> twisted" and "apt-get install twisted" and "pip install twisted" are
> going to coexist with each other. The best they can do is say "a f
2009/7/9 Tarek Ziadé :
> On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
> Ratnakumar wrote:
>> Other than easy_install/pip, there is also PyPM which is being developed at
>> ActiveState. PyPM is the Python package manager much like what ppm is for
>> ActivePerl.
>>
>
> Great ! besides the RECORD file, any
On Thu, Jul 9, 2009 at 3:42 AM, Sridhar
Ratnakumar wrote:
> Other than easy_install/pip, there is also PyPM which is being developed at
> ActiveState. PyPM is the Python package manager much like what ppm is for
> ActivePerl.
>
Great ! besides the RECORD file, anything remark on the PEP from a
PyP
On Thu, Jul 9, 2009 at 9:18 AM, Paul Moore wrote:
> 2009/7/9 Eric Smith :
>> P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
>>>
>>> Or uninstall where the installer is "setup.py install", actually.
>>
>> I think we need to
On Thu, Jul 9, 2009 at 3:07 AM, P.J. Eby wrote:
> At 09:38 AM 7/9/2009 +0900, Stephen J. Turnbull wrote:
>>
>> Eric Smith writes:
>>
>> > But I think we've veered into metadata that describes what has been
>> > installed. I don't think that's so useful. As I've said, this is
>> private
>> > to t
On Thu, Jul 9, 2009 at 12:07 AM, Eric Smith wrote:
> Paul Moore wrote:
>>
>> 2009/7/8 P.J. Eby :
>>>
>>> If it were being driven by setuptools, I'd have just implemented it
>>> myself
>>> and presented it as a fait accompli. I can't speak to Tarek's motives,
>>> but
>>> I assume that, as stated in
2009/7/9 Eric Smith :
> P.J. Eby wrote:
>>>
>>> ISTM that the problem that it solves is uninstall in the absence of
>>> the original installer.
>>
>> Or uninstall where the installer is "setup.py install", actually.
>
> I think we need to move away from "setup.py install". It's the antithesis of
>
On 03:28 am, e...@trueblade.com wrote:
Eventually, I'd like PEP 376 to support system packagers too. So for
example, if you did "apt-get install python-pyqt4", then running "pip
install python-pyqt4" should return without installing anything .. as
RECORD will be part of the .deb previously inst
On 02:55 am, e...@trueblade.com wrote:
I really don't get this use case of multiple installers trying to
install the same package. There's just no way that running "yum install
twisted" and "apt-get install twisted" and "pip install twisted" are
going to coexist with each other. The best they c
At 11:28 PM 7/8/2009 -0400, Eric Smith wrote:
Eventually, I'd like PEP 376 to support system packagers too. So
for example, if you did "apt-get install python-pyqt4", then
running "pip install python-pyqt4" should return without installing
anything .. as RECORD will be part of the .deb previous
At 11:20 PM 7/8/2009 -0400, Eric Smith wrote:
P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
Or uninstall where the installer is "setup.py install", actually.
I think we need to move away from "setup.py install". It's the
antithesi
Eventually, I'd like PEP 376 to support system packagers too. So for
example, if you did "apt-get install python-pyqt4", then running "pip
install python-pyqt4" should return without installing anything .. as
RECORD will be part of the .deb previously installed. As for generating
the RECORD fil
P.J. Eby wrote:
ISTM that the problem that it solves is uninstall in the absence of
the original installer.
Or uninstall where the installer is "setup.py install", actually.
I think we need to move away from "setup.py install". It's the
antithesis of static metadata. setup.py needs to go awa
Steven D'Aprano wrote:
On Thu, 9 Jul 2009 08:07:21 am Eric Smith wrote:
But I think we've veered into metadata that describes what has been
installed. I don't think that's so useful. As I've said, this is
private to the installers. If 2 installers want to communicate with
each other about what t
On Wed, 08 Jul 2009 09:22:52 -0700, Paul Moore wrote:
If the only driver for this PEP is setuptools, then I'm -1 on it.
Unless someone working on a packaging tool *other* than setuptools (or
setuptools-derived projects) speaks up and says "I have code of my own
which uses distutils, and I would
On Sun, 05 Jul 2009 11:46:58 -0700, Paul Moore wrote:
2009/7/5 P.J. Eby :
At 05:26 PM 7/5/2009 +0100, Paul Moore wrote:
def get_distribution(name):
for d in get_distributions():
if d.name == name:
return d
return None
Btw, this is broken code anyway, because it's no
At 09:38 AM 7/9/2009 +0900, Stephen J. Turnbull wrote:
Eric Smith writes:
> But I think we've veered into metadata that describes what has been
> installed. I don't think that's so useful. As I've said, this is private
> to the installers. If 2 installers want to communicate with each other
Stephen J. Turnbull wrote:
Eric Smith writes:
> But I think we've veered into metadata that describes what has been
> installed. I don't think that's so useful. As I've said, this is private
> to the installers. If 2 installers want to communicate with each other
> about what they've inst
On Thu, 9 Jul 2009 08:07:21 am Eric Smith wrote:
> But I think we've veered into metadata that describes what has been
> installed. I don't think that's so useful. As I've said, this is
> private to the installers. If 2 installers want to communicate with
> each other about what they've installed,
Eric Smith writes:
> But I think we've veered into metadata that describes what has been
> installed. I don't think that's so useful. As I've said, this is private
> to the installers. If 2 installers want to communicate with each other
> about what they've installed, then they can agree on
On Thu, Jul 9, 2009 at 7:07 AM, Eric Smith wrote:
> Paul Moore wrote:
>>
>> 2009/7/8 P.J. Eby :
>>>
>>> If it were being driven by setuptools, I'd have just implemented it
>>> myself
>>> and presented it as a fait accompli. I can't speak to Tarek's motives,
>>> but
>>> I assume that, as stated in
2009/7/8 Eric Smith :
> I was there, and I've been commenting!
Sorry, I hadn't realised that. Thanks for the correction.
> There might have been more discussion after the language summit and the one
> open space event I went to. But the focus as I recall was static metadata
> and version specific
Paul Moore wrote:
2009/7/8 P.J. Eby :
If it were being driven by setuptools, I'd have just implemented it myself
and presented it as a fait accompli. I can't speak to Tarek's motives, but
I assume that, as stated in the PEP, the primary driver is supporting the
distutils being able to uninstall
2009/7/8 P.J. Eby :
> If it were being driven by setuptools, I'd have just implemented it myself
> and presented it as a fait accompli. I can't speak to Tarek's motives, but
> I assume that, as stated in the PEP, the primary driver is supporting the
> distutils being able to uninstall things, and
1 - 100 of 323 matches
Mail list logo
