The reason I was a big vague is that I'm not really bothered HOW its
done, I'd just like there to be some way to use PySys_SetArgv with a
(char **)
Ok, that's easy:
void PySys_SetArgvChar(int argc, char** argv)
{
PySys_SetArgv(0, NULL);
}
So you don't bother *how* it's done as long as you
On Wed, Jul 8, 2009 at 7:09 AM, P.J. Ebyp...@telecommunity.com wrote:
At 11:30 PM 7/7/2009 +0200, Tarek Ziadé wrote:
On Tue, Jul 7, 2009 at 10:31 PM, P.J. Ebyp...@telecommunity.com wrote:
At 03:23 PM 7/7/2009 +0200, Tarek Ziadé wrote:
When I started to work on this I didn't realize the
Tarek Ziadé wrote:
On Wed, Jul 8, 2009 at 7:09 AM, P.J. Ebyp...@telecommunity.com 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
Nick Coghlan ncoghlan at 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
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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.
I
2009/7/8 Nick Coghlan ncogh...@gmail.com:
Antoine Pitrou wrote:
Nick Coghlan ncoghlan at 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
Paul Moore p.f.moore at 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
2009/7/8 Antoine Pitrou solip...@pitrou.net:
Paul Moore p.f.moore at 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
Antoine Pitrou wrote:
Paul Moore p.f.moore at 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
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
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, with a
2009/7/8 Eric Smith e...@trueblade.com:
[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
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
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
Hello,
2009/7/8 Erik Groeneveld e...@cq2.nl:
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
On Wed, Jul 8, 2009 at 5:11 PM, P.J. Ebyp...@telecommunity.com 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
2009/7/8 P.J. Eby p...@telecommunity.com:
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
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
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
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 p...@telecommunity.com:
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,
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?
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 because
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 first
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.
2009/7/8 P.J. Eby p...@telecommunity.com:
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
Paul Moore wrote:
2009/7/8 P.J. Eby p...@telecommunity.com:
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
2009/7/8 Eric Smith e...@trueblade.com:
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
On Thu, Jul 9, 2009 at 7:07 AM, Eric Smithe...@trueblade.com wrote:
Paul Moore wrote:
2009/7/8 P.J. Eby p...@telecommunity.com:
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
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,
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 p.f.mo...@gmail.com wrote:
2009/7/5 P.J. Eby p...@telecommunity.com:
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,
On Wed, 08 Jul 2009 09:22:52 -0700, Paul Moore p.f.mo...@gmail.com 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
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
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
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
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 away.
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 file,
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
antithesis
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 previously
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
42 matches
Mail list logo
