On Jun 04, 2010, at 01:07 PM, Ian Bicking wrote:
>On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw wrote:
>
>> >So at the end, the end user would chose an installer that is
>> >compatible with these archive, and know how to install them. In other
>> >words, have ez_setup for example, run once for all
On 4 Jun 2010, at 20:07, Ian Bicking wrote:
SuSE sponsored the opensuse build server for that purpose: providing a
build server insulated from the developers environment.
https://build.opensuse.org/
They provide yum/yast repositories so binaries can be downloaded automatically
(like in the easy
On Thu, Jun 3, 2010 at 8:38 AM, Barry Warsaw wrote:
> >So at the end, the end user would chose an installer that is
> >compatible with these archive, and know how to install them. In other
> >words, have ez_setup for example, run once for all at the Python
> >level, and be THE installer. Or run a
On Jun 04, 2010, at 01:10 AM, Ben Finney wrote:
>Barry Warsaw writes:
>
>> On May 29, 2010, at 09:12 PM, Tarek Ziadé wrote:
>>
>> >That's the point I am trying to express: it's "implicit, embed,
>> >installers in project's setup.py" vs "an installer globally installed,
>> >knowing how to install
Barry Warsaw writes:
> On May 29, 2010, at 09:12 PM, Tarek Ziadé wrote:
>
> >That's the point I am trying to express: it's "implicit, embed,
> >installers in project's setup.py" vs "an installer globally installed,
> >knowing how to install projects that follows a given standard"
>
> I feel prett
On May 29, 2010, at 09:12 PM, Tarek Ziadé wrote:
>That's the point I am trying to express: it's "implicit, embed,
>installers in project's setup.py" vs "an installer globally installed,
>knowing how to install projects that follows a given standard"
I feel pretty firmly that the choice of install
On May 29, 2010, at 10:19 AM, Tarek Ziadé wrote:
>I think separating the concerns and letting the end user pick/use
>explicitly *one* installer globally is better because several
>installers won't compete on the target system (even if we supposely
>want them all to be compatible in the future). Of
On 3 Jun, 2010, at 9:50, Tarek Ziadé wrote:
> On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren
> wrote:
>>
>> On 31 May, 2010, at 19:10, Tarek Ziadé wrote:
>>
>>> On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote:
On Mon, May 31, 2010 at 19:02, Carl Meyer wrote:
> Nope, pip's u
On 3 Jun, 2010, at 10:38, Tarek Ziadé wrote:
> On Thu, Jun 3, 2010 at 10:24 AM, Ronald Oussoren
> wrote:
> [..]
>> A full switch to PEP 376. An option to enable/disable would just be
>> confusing, any option increases the mental load of developers (and anyone
>> that just wants to install a
On Thu, Jun 3, 2010 at 10:24 AM, Ronald Oussoren wrote:
[..]
> A full switch to PEP 376. An option to enable/disable would just be
> confusing, any option increases the mental load of developers (and anyone
> that just wants to install a python package to use its functionality) and in
> this c
On Thu, Jun 3, 2010 at 10:02, Ronald Oussoren wrote:
> I know that distutils in python 2. 6 and 3.1 won't support PEP 376, but why
> won't distutils conform to PEP 376 in python 2.7 and 3.2?
Correct me if I'm wrong here, but there is a lot of PEPs regarding
distutils, and it was simply decided t
On 3 Jun, 2010, at 10:10, Tarek Ziadé wrote:
> On Thu, Jun 3, 2010 at 10:02 AM, Ronald Oussoren
> wrote:
>>
>> On 3 Jun, 2010, at 9:50, Tarek Ziadé wrote:
>>
>>> On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren
>>> wrote:
On 31 May, 2010, at 19:10, Tarek Ziadé wrote:
> O
On Thu, Jun 3, 2010 at 10:02 AM, Ronald Oussoren wrote:
>
> On 3 Jun, 2010, at 9:50, Tarek Ziadé wrote:
>
>> On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren
>> wrote:
>>>
>>> On 31 May, 2010, at 19:10, Tarek Ziadé wrote:
>>>
On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote:
> On
On Thu, Jun 3, 2010 at 9:15 AM, Ronald Oussoren wrote:
>
> On 31 May, 2010, at 19:10, Tarek Ziadé wrote:
>
>> On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote:
>>> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote:
Nope, pip's used --record on installation for years, and the above has
>
On 31 May, 2010, at 19:10, Tarek Ziadé wrote:
> On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote:
>> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote:
>>> Nope, pip's used --record on installation for years, and the above has
>>> been true since the moment uninstall landed in pip. There ar
On Fri, May 28, 2010 at 6:13 PM, Tarek Ziadé wrote:
> Hello,
>
> Distutils2 is going to be added back in Python (hopefully in 3.2) and
> without an install script, it's pretty useless as-is.
>
> We've discussed during the summit at Pycon to create some kind of
> bootstrap script in Python, to all
On Tue, Jun 1, 2010 at 5:12 AM, Ian Bicking wrote:
[..]
> In terms of release cycles I'm also somewhat uncomfortable with the
> extraction of the VCS support... it feels more like a political concession
> than a good technical decision. I don't want the brokenness of the stdlib
> process to drive
On Mon, May 31, 2010 at 10:11 AM, Tarek Ziadé wrote:
> On Mon, May 31, 2010 at 4:55 PM, Ian Bicking wrote:
> [..]
> > Well, I could list the problems, but basically I strongly dislike the
> idea
> > that, say, Python 3.2 will ship distutils2 with a certain version of pip,
> > and that people wou
On Mon, May 31, 2010 at 7:10 PM, Carl Meyer wrote:
> Lennart Regebro wrote:
>> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote:
>>> Nope, pip's used --record on installation for years, and the above has
>>> been true since the moment uninstall landed in pip. There are enough
>>> different ways th
On Mon, May 31, 2010 at 19:10, Tarek Ziadé wrote:
> You mean in the current distutils ? Because distutils2 will have the
> PEP 376 implementation,
> where we create a RECORD file for each installed project in its dist-info/
Good.
I suffer from PEP overload, and have long since given up on
rememb
On Mon, May 31, 2010 at 7:04 PM, Lennart Regebro wrote:
> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote:
>> Nope, pip's used --record on installation for years, and the above has
>> been true since the moment uninstall landed in pip. There are enough
>> different ways things can get installed t
Lennart Regebro wrote:
> On Mon, May 31, 2010 at 19:02, Carl Meyer wrote:
>> Nope, pip's used --record on installation for years, and the above has
>> been true since the moment uninstall landed in pip. There are enough
>> different ways things can get installed that it's not surprising that
>> so
On Sun, May 30, 2010 at 11:17 PM, P.J. Eby wrote:
> At 09:12 PM 5/29/2010 +0200, Tarek Ziadé wrote:
>>
>> > For packages with complex build requirements or distutils extensions
>> > (e.g.
>> > numpy), this is unlikely to happen any time soon.
>> >
>> > Conversely, for packages where this *is* the
On Mon, May 31, 2010 at 19:02, Carl Meyer wrote:
> Nope, pip's used --record on installation for years, and the above has
> been true since the moment uninstall landed in pip. There are enough
> different ways things can get installed that it's not surprising that
> some discussions may have been
Lennart Regebro wrote:
> On Mon, May 31, 2010 at 16:55, Carl Meyer wrote:
>> Not true, inasmuch as it depends on pip. When pip installs distributions
>> it uses the --record option to keep a list of all installed files. When
>> pip uninstalls distributions it installed, it reliably uninstalls
>> e
On Mon, May 31, 2010 at 16:55, Carl Meyer wrote:
> Not true, inasmuch as it depends on pip. When pip installs distributions
> it uses the --record option to keep a list of all installed files. When
> pip uninstalls distributions it installed, it reliably uninstalls
> everything (though it doesn't
On Mon, May 31, 2010 at 4:55 PM, Ian Bicking wrote:
[..]
> Well, I could list the problems, but basically I strongly dislike the idea
> that, say, Python 3.2 will ship distutils2 with a certain version of pip,
> and that people would have to upgrade Python or wait for a Python release to
> get upg
On Sun, May 30, 2010 at 12:13 PM, Carl Meyer wrote:
> I sympathize with the ease-of-use reasons for having something in the
> stdlib. And I'm not sure putting pip in the stdlib would be good for
> pip's development.
>
This is my primary concern. I have no problem with merging pip with
distutils
Hi Lennart,
Lennart Regebro wrote:
>> You are aware that pip uninstalls?
>
> Not reliably, as it doesn't keep track of files, so it can't remove
> anything installed outside of the package.
Not true, inasmuch as it depends on pip. When pip installs distributions
it uses the --record option to ke
Tarek Ziadé wrote:
> I won't speak for others, but on my side, I don't underestimate the
> amount of work involved in an installer (heck, if I was scared by the
> amount of work in packaging, I'd quit 2 years ago ;)), but rather
> trying to figure out what is the path for a better packaging
> eco
On Sun, May 30, 2010 at 22:57, Tarek Ziadé wrote:
> So, I am still proposing to merge both projects and to have two kinds
> of releases:
>
> - distutils2 + pip included (maybe a renamed script)
I don't think this is necessary. Sure, distutils without an installer
is kinda crippled, but the people
On Sun, May 30, 2010 at 19:13, Carl Meyer wrote:
> Lennart Regebro wrote:
>> 1. We include easy_install or pip in stdlib. However, I think we
>> shouldn't include any installer in stdlib, until it has evolved into a
>> proper package handling utility which also can uninstall, etc.
>
> You are awar
At 09:12 PM 5/29/2010 +0200, Tarek Ziadé wrote:
> For packages with complex build requirements or distutils extensions (e.g.
> numpy), this is unlikely to happen any time soon.
>
> Conversely, for packages where this *is* the case, the current distutils is
> adequate, and having a bootstrapper th
On Sun, May 30, 2010 at 7:13 PM, Carl Meyer wrote:
[..]
>
> I sympathize with the ease-of-use reasons for having something in the
> stdlib. And I'm not sure putting pip in the stdlib would be good for
> pip's development. So I don't have a solution to propose. But I have a
> hard time believing th
Lennart Regebro wrote:
> 1. We include easy_install or pip in stdlib. However, I think we
> shouldn't include any installer in stdlib, until it has evolved into a
> proper package handling utility which also can uninstall, etc.
You are aware that pip uninstalls? It also queries PyPI, lists locally
Hi
[Tarek]
>> I was not thinking about this proposal. If this what Guido proposed at
>> the summit, then I misunderstood.
[PJE]
> I don't know what he proposed at the summit - I'm referring to the
> bootstrap script he wrote that actually does this. It was a couple
> years ago on Python-Dev, II
On Sat, May 29, 2010 at 6:32 PM, P.J. Eby wrote:
[..]
>
> So? It's not like they're going to accidentally run 'easy_install' when
> they meant to type 'pip', or vice versa. ;-)
They will accidentally run easy_install through a simple "python
setup.py install" call if the given project bootstrap
I'm not sure I understand this thread, mainly because I though
distutils2 was to provide an installer. :) So with the risk of me not
understanding it, here goes:
I think both proposals, both the older bootstrap script and the summit
proposal, is to make it easy to install an installer, which in
pr
At 10:19 AM 5/29/2010 +0200, Tarek Ziadé wrote:
I was not thinking about this proposal. If this what Guido proposed at
the summit, then I misunderstood.
I don't know what he proposed at the summit - I'm referring to the
bootstrap script he wrote that actually does this. It was a couple
years
On Sat, May 29, 2010 at 10:19 AM, Tarek Ziadé wrote:
[..]
>
> It will also allow distributions to be "dumb" envelopes with static
> metadata that are the same all the time, no matter which tool created
> them, and eventually remove setup.py in favor of statically described
> metadata using PEP 345
2010/5/29 P.J. Eby :
> At 01:13 AM 5/29/2010 +0200, Tarek Ziadé wrote:
>>
>> The problem I have with this approach is that we need to manage
>> somewhere at PyPI a list of potential installers,
>> and maybe deal with upgrades and replacements. Plus, I am not sure
>> that a user will really understa
At 01:13 AM 5/29/2010 +0200, Tarek Ziadé wrote:
The problem I have with this approach is that we need to manage
somewhere at PyPI a list of potential installers,
and maybe deal with upgrades and replacements. Plus, I am not sure
that a user will really understand what to
do when he's asked to cho
Hello,
Distutils2 is going to be added back in Python (hopefully in 3.2) and
without an install script, it's pretty useless as-is.
We've discussed during the summit at Pycon to create some kind of
bootstrap script in Python, to allow people to
set up an installer of their choice, but I think it's
43 matches
Mail list logo
