Tarek Ziadé wrote:
> On Wed, Jul 8, 2009 at 7:09 AM, P.J. Eby wrote:
>> So I punned on that in order to imply that nobody who takes on the job of
>> packaging expects to be asked the kind of detailed, unanswerable questions
>> that come with the territory of packaging, or to be subjected to torture
Nick Coghlan gmail.com> writes:
>
> I think is exchange actually a good reminder that the bar for acceptance
> of PEP 376 shouldn't be "Addresses every possible packaging issue we can
> come up with". That would be setting expectations far too high because
> packaging cross-platform is so messy.
Antoine Pitrou wrote:
> Nick Coghlan gmail.com> writes:
>> For example, I quite like the concept behind the various ideas for
>> "location" or "prefix" definitions either in the RECORD file itself or
>> in a separate PREFIXES file, since such approaches feeds directly in to
>> part b) above.
>
>
2009/7/8 Nick Coghlan :
> Antoine Pitrou wrote:
>> Nick Coghlan gmail.com> writes:
>>> For example, I quite like the concept behind the various ideas for
>>> "location" or "prefix" definitions either in the RECORD file itself or
>>> in a separate PREFIXES file, since such approaches feeds directly
Paul Moore gmail.com> writes:
>
> I have no answer here. But I think we need feedback from the people
> who will ultimately be building bdist_xxx formats - Debian packagers,
> people wrting alternate RPM builders, etc.
I think any bdist_xxx command which targets externally handled package format
2009/7/8 Antoine Pitrou :
> Paul Moore gmail.com> writes:
>>
>> I have no answer here. But I think we need feedback from the people
>> who will ultimately be building bdist_xxx formats - Debian packagers,
>> people wrting alternate RPM builders, etc.
>
> I think any bdist_xxx command which targets
Antoine Pitrou wrote:
Paul Moore gmail.com> writes:
I have no answer here. But I think we need feedback from the people
who will ultimately be building bdist_xxx formats - Debian packagers,
people wrting alternate RPM builders, etc.
I think any bdist_xxx command which targets externally handl
L.S.
I am working on an extension that allows one to open Java .jar files
and use the objects defined in it (via CNI or JNI) in Python. It
works like a charm, but I am stuck with the definition of a metatype
for the wrappers. I have to do this in Python now, with a helper
class.
I did find exam
Erik Groeneveld wrote:
> L.S.
>
> I am working on an extension that allows one to open Java .jar files
> and use the objects defined in it (via CNI or JNI) in Python. It
> works like a charm, but I am stuck with the definition of a metatype
> for the wrappers. I have to do this in Python now, wi
2009/7/8 Eric Smith :
> [Any reason you didn't respond to the list? I'd like to continue the
> discussion there. But I'm currently replying just to you.]
No, I just clicked the wrong button. Sorry. Redirecting back to the list.
> Paul Moore wrote:
>>
>> 2009/7/8 Eric Smith :
>>>
>>> I agree with
At 01:13 PM 7/8/2009 +0100, Paul Moore wrote:
An alternative solution would be for the bdist_xxx commands to ignore
the RECORD file generated in the temp area, and build its own on the
target machine when the installer is run. This is conceptuially far
cleaner, it's in line with the implicit assu
At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
Who's going to use the APIs based around the RECORD file? Anyone?
The distutils uninstall facility, for starters. easy_install and pip
also will, eventually.
In all three cases, the use will be in order to avoid overwriting
files belonging to a
Hello,
2009/7/8 Erik Groeneveld :
> I am working on an extension that allows one to open Java .jar files
> and use the objects defined in it (via CNI or JNI) in Python. It
> works like a charm, but I am stuck with the definition of a metatype
> for the wrappers. I have to do this in Python now,
On Wed, Jul 8, 2009 at 5:11 PM, P.J. Eby wrote:
> At 01:13 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> An alternative solution would be for the bdist_xxx commands to ignore
>> the RECORD file generated in the temp area, and build its own on the
>> target machine when the installer is run. This is co
2009/7/8 P.J. Eby :
> At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> Who's going to use the APIs based around the RECORD file? Anyone?
>
> The distutils uninstall facility, for starters. easy_install and pip also
> will, eventually.
Is pip getting this via setuptools, or will it be independe
P.J. Eby wrote:
At 08:59 AM 7/8/2009 -0400, Eric Smith wrote:
I agree with this. For RPM's, there's a whole other database of what
files were installed. Is it really the intent that a file will be
managed by multiple different installers? That I can install with RPM
but remove with some python
I am confused by the current hydra-like development. I've recently
submitted a change (issue6422 -- a feature request) which is currently
moving through the process. I am not particularly asking for special
attention on that issue, but I am confused about the process I should be
using (in the fa
Hi,
> There seem to be two places to plausibly introduce a change: py3k and
> trunk. Should I submit changes for trunk, py3k, or both? I tried
> asking in the initial feature request, but nobody replied, and I finally
> decided that I'd go for patching trunk in the interim.
Patches are usually
At 05:22 PM 7/8/2009 +0100, Paul Moore wrote:
2009/7/8 P.J. Eby :
> At 03:57 PM 7/8/2009 +0100, Paul Moore wrote:
>>
>> Who's going to use the APIs based around the RECORD file? Anyone?
>
> The distutils uninstall facility, for starters. easy_install and pip also
> will, eventually.
Is pip gett
At 01:58 PM 7/8/2009 -0400, Eric Smith wrote:
I really don't see this use case. Supporting multiple installers for
the same file (or even just trying to prevent two installers from
writing the same file)? Wouldn't you be better off just saying an
installer can't overwrite any existing file?
L
>> Hehe very nice, thanks for the explanation :)
>>
>> (thanks to the others too)
>
> I think is exchange actually a good reminder that the bar for acceptance
> of PEP 376 shouldn't be "Addresses every possible packaging issue we can
> come up with". That would be setting expectations far too high
>> There seem to be two places to plausibly introduce a change: py3k and
>> trunk. Should I submit changes for trunk, py3k, or both? I tried
>> asking in the initial feature request, but nobody replied, and I finally
>> decided that I'd go for patching trunk in the interim.
>
> Patches are usual
Martin v. Löwis wrote:
There seem to be two places to plausibly introduce a change: py3k and
trunk. Should I submit changes for trunk, py3k, or both?
Patches are usually first checked into trunk, and then svnmerge'd to py3k.
So it makes more sense to submit your patch against trunk.
For
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
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 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
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
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, 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,
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
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
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
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
Is there any reason why RECORD file can't be generated at runtime? Also,
why should the RECORD file be generated at all by bdist* commands?
A .deb file contains "data.tar.gz" that is simply extracted over "/".
There is no need for RECORD inside a .deb file because it is implicit in
the cont
At 06:51 PM 7/8/2009 -0700, Sridhar Ratnakumar wrote:
Is there any reason why RECORD file can't be generated at runtime?
Applications can be relocatable, yet require plugins and libraries to
be upgraded, installed, uninstalled, etc.
(Also, RECORD is cross-platform to allow cross-platform
in
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
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
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
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
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
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
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
42 matches
Mail list logo
