Thank you! The sensitivity of this issue obviously is born out of our
collective
bad conscience for this unjust incarceration.
K
> -Original Message-
> From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf
> Of Guido van Rossum
> >
> > This fixes a regression in marshal betw
But that's what hg clone does.
You have a lorry for your work at the mine. You don't need a Mini to go to the
fishmongers. You can use your lorry even if you are not going to dump a tonne
of ore on the pavement.
K
> -Original Message-
>
> What would be good would to be able to access
On Sun, Nov 18, 2012 at 04:18:43AM -0800, mar...@v.loewis.de wrote:
> I'd like to stress that we don't need any versioning here. wget and
> tar would be sufficient, except that it's Windows, so we have neither
> wget nor tar. However, including a PowerShell script may be an option;
> most developer
Hi all,
Along with a number of other free and open communities, Python is
being included in a survey of new contributors since January 2010. The
survey is being done by Kevin Carillo, a PhD student at Victoria
University of Wellington who is studying various approaches that
projects use to gain an
I think this PEP is a significant improvement from its predecessor. It
represents features like extras (provides-extra) and build requirements
(setup-requires-dist) that are in use in the Python community but cannot be
represented in older versions of the format, it finally specifies a UTF-8
encodi
On Mon, Nov 19, 2012 at 6:53 PM, Daniel Holth wrote:
> I think this PEP is a significant improvement from its predecessor. It
> represents features like extras (provides-extra) and build requirements
> (setup-requires-dist) that are in use in the Python community but cannot be
> represented in ol
On Monday, November 19, 2012 at 7:37 PM, PJ Eby wrote:
> Can we maybe kill Provides-Dist and its associated baggage first, though?
>
>
I would love to kill Provides-Dist. The biggest question there is how do you
handle it's
functionality? If someone needs setuptools but they have distribute ins
Does it really have baggage? I think it is necessary, although it doesn't do
favors to the implementer (and has never been implemented). How else is anyone
supposed to fork or merge projects?
Daniel Holth
On Nov 19, 2012, at 7:37 PM, PJ Eby wrote:
> On Mon, Nov 19, 2012 at 6:53 PM, Daniel Hol
The "I bundled a renamed copy of six" is a totally different case which would
not invoke provides-dist. "I merged sqlalchemy with a previously separate but
wildly popular declarative / database support / whatever extension" would
invoke provides-dist.
Daniel Holth
On Nov 19, 2012, at 7:41 PM,
Other languages seem to get along fine without it. Even the OS
managers which have it don't allow it to be used to masquerade
as another project, only to make generic virtual packages (e.g. "email").
On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote:
> Does it really have baggage? I t
The distro repos are centrally managed, too. Try getting setuptools to provide
a virtual package just because you want to fork.. and then update the dependent
packages?
Daniel Holth
On Nov 19, 2012, at 7:49 PM, Donald Stufft wrote:
> Other languages seem to get along fine without it. Even the
On Monday, November 19, 2012 at 8:08 PM, Daniel Holth wrote:
> The distro repos are centrally managed, too. Try getting setuptools to
> provide a virtual package just because you want to fork.. and then update the
> dependent packages?
>
> Daniel Holth
Sorry didn't mean to make it sound like I t
We are getting along fine too. No tool parses metadata 1.x for package
management reasons and provides has existed forever with no implementation. So
it is not inconveniencing anyone. I would prefer to leave it alone.
Daniel Holth
On Nov 19, 2012, at 7:49 PM, Donald Stufft wrote:
> Other lang
So you want to leave metadata in that you think people shouldn't implement?
Or you do think people should implement it and the point about it existing
forever without an implementation is?
At the very least there needs to be some sort of guidelines as to what
to do with the field in the various
On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote:
> Other languages seem to get along fine without it. Even the OS
> managers which have it don't allow it to be used to masquerade
> as another project, only to make generic virtual packages (e.g. "email").
>
I'm not sure this assertion
On Monday, November 19, 2012 at 8:35 PM, Toshio Kuratomi wrote:
> On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote:
> > Other languages seem to get along fine without it. Even the OS
> > managers which have it don't allow it to be used to masquerade
> > as another project, only to make
Daniel Holth writes:
> Does [Provides-Dist] really have baggage? I think it is necessary,
> although it doesn't do favors to the implementer (and has never
> been implemented). How else is anyone supposed to fork or merge
> projects?
It doesn't bother me personally if this traffic is on pytho
Look more closely at the docs for "Obsoletes" in RPM, not just those for
"Provides". Being able to transparently replace an existing package with a
renamed one that installs files with the same names is certainly part of
the purpose/capabilities of the RPM dependency machinery (i.e. precisely
the d
On Monday, November 19, 2012 at 9:01 PM, Nick Coghlan wrote:
> Look more closely at the docs for "Obsoletes" in RPM, not just those for
> "Provides". Being able to transparently replace an existing package with a
> renamed one that installs files with the same names is certainly part of the
> pu
Mostly it seems a bit silly to have so much conversations about parts of
the pep that remain unchanged from previously accepted versions...
On Nov 19, 2012 8:33 PM, "Donald Stufft" wrote:
> So you want to leave metadata in that you think people shouldn't
> implement?
>
> Or you do think people s
On Monday, November 19, 2012 at 9:24 PM, Daniel Holth wrote:
> Mostly it seems a bit silly to have so much conversations about parts of the
> pep that remain unchanged from previously accepted versions...
Well, I think the PEP should describe what we expect to be implemented *shrug*.
Either we
The section could definitely be much clearer. How about:
Provides-Dist (multiple use)
Each entry contains a string naming a requirement that is satisfied by
installing this distribution. This field *must* include the project
identified in the ``Name`` field, optionally followed by the version:
N
22 matches
Mail list logo
