ajaksu wrote:
> While Linux and OS X both view Python as essentially a first-class
> development platform-i.e., as something that shrink-wrap applications
> can be built on-Windows does not.
Even on MacOSX and Linux, you can't rely on the system
coming with the particular version of Python you wan
In article
<[EMAIL PROTECTED]>,
ajaksu <[EMAIL PROTECTED]> wrote:
> [...] While Linux and OS X both view Python as essentially a first-class
> development platform-i.e., as something that shrink-wrap applications
> can be built on-Windows does not. Instead, it's generally expected
> that a Python
> (Note: I'm aware that people believe it to be necessary to munge the
> Windows registry when installing Python packages; I just don't agree
> with the practice, and don't think we should distort Python's process
> to coddle it).
Whoever thinks it necessary is misguided. Installing a package d
On Mar 22, 5:13 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Can you give me a
> > pointer to Aza Raskin's keynote? Is it online anywhere? I'd be
> > interested in his point of view.
>
> Unfortunately no. I was looking for it, but couldn't find it. He
> mentioned a website with a "call for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
>> Oh, and application installation is (should be) completely different.
>> On Windows, applications should probably be bundled with their own
>> Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
>> standard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
>>> Sure, but what is precisely the semantics of uninstallation, in
>>> terms of changes to the system state?
>>>
>>> I think any model where uninstallation is merely the removal
>>> of files is too limited to be practical.
>> Th
ajaksu wrote:
> On Mar 22, 5:13 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Unfortunately no. I was looking for it, but couldn't find it. He
>> mentioned a website with a "call for action", but I couldn't find
>> that, either :-(
>
> As I tried to reply (in a message that is waiting for mo
A.M. Kuchling wrote:
> On Sat, Mar 22, 2008 at 09:13:24PM +0100, "Martin v. L?wis" wrote:
>> Unfortunately no. I was looking for it, but couldn't find it. He
>> mentioned a website with a "call for action", but I couldn't find
>> that, either :-(
>
> We're working on the video, but I think it'll b
On Mar 22, 5:13 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Unfortunately no. I was looking for it, but couldn't find it. He
> mentioned a website with a "call for action", but I couldn't find
> that, either :-(
As I tried to reply (in a message that is waiting for moderation), the
site see
On Sat, Mar 22, 2008 at 09:13:24PM +0100, "Martin v. L?wis" wrote:
> Unfortunately no. I was looking for it, but couldn't find it. He
> mentioned a website with a "call for action", but I couldn't find
> that, either :-(
We're working on the video, but I think it'll be a few weeks before
things st
>>> Oh, and application installation is (should be) completely different.
>> > On Windows, applications should probably be bundled with their own
>> > Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
>> > standard is, so I'd have to defer to others.
>>
>>
>> This I disagree
On 22/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Oh, and application installation is (should be) completely different.
> > On Windows, applications should probably be bundled with their own
> > Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
> > standard is,
> Oh, and application installation is (should be) completely different.
> On Windows, applications should probably be bundled with their own
> Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
> standard is, so I'd have to defer to others.
This I disagree with. I think it's an
>> Sure, but what is precisely the semantics of uninstallation, in
>> terms of changes to the system state?
>>
>> I think any model where uninstallation is merely the removal
>> of files is too limited to be practical.
>
> The distutils only support the *addition* of files, so I'm not sure
> how
> Huh? How's that? Don't forget that I'm on Windows, and on Windows
> there is no "system tool" - just bdist_wininst, bdist_msi and
> easy_install. The fact that bdist_wininst and bdist_msi link into the
> system UI for listing and uninstallation doesn't make packages using
> them "system packages"
Neal Becker wrote:
> Another use case, which I find in my world, is that there are always
> packages that interest me (found at pypi), that my vendor hasn't packaged
> as rpms yet.
>
> With finite resources, this will always be true.
Why do you need a package database for that? Can't you just run
> I more question the permissions and uid/gid stuff; I'm not really
> clear on what I'd use that stuff for in easy_install/uninstall/etc.
I think this was all captured in amk's statement "RPM-like
verification". RPM not only verifies file content, but also whether
the permissions are all correct.
At 04:29 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>>For those without the read-only flag, the specification should
>>>explicitly say what manipulation is allowed.
>>Since a distribution isn't really "mutable", I would think that
>>uninstallation and reinstallation would be the only manipulation
On 22/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> This probably needs to be refined a little. Exclusive right is too
> strong, and it goes against Paul Moore's desire for using a single
> tool.
Huh? How's that? Don't forget that I'm on Windows, and on Windows
there is no "system tool"
At 11:19 AM 3/22/2008 -0400, Phillip J. Eby wrote:
>Not exactly. More like, "package management tool X claims exclusive
>rights to this package". Python tools would always defer this right
>to the system packager, i.e. a system packager is not obliged to
>respect a Python tool's claim to a file,
>> For those without the read-only flag, the specification should
>> explicitly say what manipulation is allowed.
>
> Since a distribution isn't really "mutable", I would think that
> uninstallation and reinstallation would be the only manipulation
> available. (As distinct from inspection, ver
At 12:33 PM 3/22/2008 +0100, Martin v. Löwis wrote:
>>I probably should have brought this up, in fact, I think I
>>mentioned it in a previous thread, but I would like to see PEP 262
>>add a way to say "this is a system-installed package, *don't
>>touch*". The idea again is not to do the job of
On 22/03/2008, Steve Holden <[EMAIL PROTECTED]> wrote:
> Well, I've probably been killfiled into non-existence on this list by
> now, but it seems to me that we are in danger of answering the wrong
> problem yet again. But that's all I have to say on this topic, so you
> can all heave a sigh a r
> Ok, well, I have a rationale for it: make it possible to get rid of eggs
> as a mechanism for supporting easy_install. Many people (yourself
> included) have criticized eggs as an installation mechanism, and this is
> an alternative that gets rid of .egg files and directories in that case,
>
M.-A. Lemburg wrote:
> On 2008-03-21 22:21, Phillip J. Eby wrote:
>> At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>>> I guess the only way to support all of these variants is
>>> to use a filesystem based approach, e.g. by placing a file
>>> with a special extension into some dir on sys.path.
Another use case, which I find in my world, is that there are always
packages that interest me (found at pypi), that my vendor hasn't packaged
as rpms yet.
With finite resources, this will always be true.
___
Python-Dev mailing list
Python-Dev@python.or
On 22 Mar, 2008, at 2:44, A.M. Kuchling wrote:
On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
I'm making the assumption that the author(s) of PEP 262 had good
reason for including what they did, rather than assuming that we
should start the entire process over from scratch.
T
Phillip J. Eby wrote:
> At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
>> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
>> Joachim> files (and 'rmdir' directories, but not recursively) that it
>> Joachim> created, and that have not been modified in the m
At 09:44 PM 3/21/2008 -0400, A.M. Kuchling wrote:
>On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
> > I'm making the assumption that the author(s) of PEP 262 had good
> > reason for including what they did, rather than assuming that we
> > should start the entire process over from
At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
>>I'm making the assumption that the author(s) of PEP 262 had good
>>reason for including what they did, rather than assuming that we
>>should start the entire process over from scratch.
>
>The objections to the PEP remain the same as they were
On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
> I'm making the assumption that the author(s) of PEP 262 had good
> reason for including what they did, rather than assuming that we
> should start the entire process over from scratch.
The goal *was* originally to provide for RPM-
> I'm making the assumption that the author(s) of PEP 262 had good
> reason for including what they did, rather than assuming that we
> should start the entire process over from scratch.
The objections to the PEP remain the same as they were then,
though: In the requirements, it says "we need",
At 11:13 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>On 2008-03-21 22:21, Phillip J. Eby wrote:
> > At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
> >> I guess the only way to support all of these variants is
> >> to use a filesystem based approach, e.g. by placing a file
> >> with a special exten
On 2008-03-21 22:21, Phillip J. Eby wrote:
> At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>> I guess the only way to support all of these variants is
>> to use a filesystem based approach, e.g. by placing a file
>> with a special extension into some dir on sys.path.
>> The "database" logic cou
At 05:59 PM 3/21/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby schrieb:
> > Questions, comments... volunteers? :)
>
>I've yet to read the monster package utils thread so I can't comment on
>it. However I like to draw some attention to my PEP 370
>http://python.org/dev/peps/pep-0370/. It's
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>I guess the only way to support all of these variants is
>to use a filesystem based approach, e.g. by placing a file
>with a special extension into some dir on sys.path.
>The "database" logic could then scan sys.path for these
>files, read the data
On 21/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Questions, comments... volunteers? :)
Sounds good. I won't volunteer as I have neither time nor expertise to
contribute much. But I'd like to see this happen, as it sounds like it
would address all my issues with setuptools (and just
Phillip J. Eby wrote:
> Questions, comments... volunteers? :)
This makes a lot of sense. I don't really have anything to add in terms
of implementation, but I wonder if we can learn something from how apt
or rpms or ports work, and how other programming languages (Ruby gems?)
solve this.
I
On 2008-03-21 14:47, Phillip J. Eby wrote:
> So, to accomplish this, we (for some value of "we") need to:
>
> 1. Hash out consensus around what changes or enhancements are needed
> to PEP 262, to resolve the previously-listed open issues, those that
> have come up since (namespace packages, depe
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
> Joachim> files (and 'rmdir' directories, but not recursively) that it
> Joachim> created, and that have not been modified in the meantime (after
> Joachi
[EMAIL PROTECTED] writes:
>
> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
> Joachim> files (and 'rmdir' directories, but not recursively) that it
> Joachim> created, and that have not been modified in the meantime (after
> Joachim> the installation)
Phillip J. Eby schrieb:
> Questions, comments... volunteers? :)
I've yet to read the monster package utils thread so I can't comment on
it. However I like to draw some attention to my PEP 370
http://python.org/dev/peps/pep-0370/. It's about a site packages
directory in the users home directory.
Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim> files (and 'rmdir' directories, but not recursively) that it
Joachim> created, and that have not been modified in the meantime (after
Joachim> the installation).
That's not sufficient. Suppose file
On Fri, Mar 21, 2008 at 2:47 PM, Phillip J. Eby <[EMAIL PROTECTED]>
wrote:
> Second, there were no uninstall tools for it, so I'd have had to
> write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
> ain't easy, and I have an aversion to deleting stuff on people's
> systems without
Phillip J. Eby wrote:
> Second, there were no uninstall tools for it, so I'd have had to
> write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
> ain't easy, and I have an aversion to deleting stuff on people's
> systems without knowing what will break. There's a big difference
45 matches
Mail list logo
