>
> I also think it is reasonable to continue offering a feature like
> dependency_links on an opt-in basis for controlled environments (I see
> it as analagous to the direct references feature in PEP 440).
>
>
with pip already, the idea** is that you can enforce a concrete location
for a
dependenc
> "we don't know what happens inside corporate firewalls"
>
non-published use of dependency links could turn out to be the use-cases
that we'd get complaints about
> To me, the best part of the more aggressive timeline is it means
> CPython would never ship a version of pip that allows that par
On 27 Oct 2013 18:38, "Marcus Smith" wrote:
>
>
>>
>> "we don't know what happens inside corporate firewalls"
>
>
> non-published use of dependency links could turn out to be the use-cases
that we'd get complaints about
>
>
>>
>> To me, the best part of the more aggressive timeline is it means
>>
More numbers, of the 411 projects who have ever used dependency links, only 311
of them use them in their latest release.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GP
Here’s the list of dependency links for the projects that still use them in
their latest releases:
https://gist.github.com/dstufft/7185162
A good number of them are either bogus, are pointing directly to PyPI, or are
file:// urls that are highly unlikely to exist on anyones computer but the
au
On Sun, Oct 27, 2013 at 10:44 AM, Donald Stufft wrote:
> Here’s the list of dependency links for the projects that still use them
> in their latest releases:
>
> https://gist.github.com/dstufft/7185162
>
> A good number of them are either bogus, are pointing directly to PyPI, or
> are file:// url
On 28 Oct 2013 03:44, "Donald Stufft" wrote:
>
> Here’s the list of dependency links for the projects that still use them
in their latest releases:
>
> https://gist.github.com/dstufft/7185162
>
> A good number of them are either bogus, are pointing directly to PyPI, or
are file:// urls that are hi
Hi Nick, all,
PEP426 and its prior related peps see project-specific metadata as part
of distribution metadata. Main examples are "project urls" such as
"home page", "repository", "issue tracker" or contact points such as
mailing lists, maintainer emails etc. However, at any point in time
there
On 28 Oct 2013 06:56, "holger krekel" wrote:
>
> Hi Nick, all,
>
> PEP426 and its prior related peps see project-specific metadata as part
> of distribution metadata. Main examples are "project urls" such as
> "home page", "repository", "issue tracker" or contact points such as
> mailing lists, m
On Sun, Oct 27, 2013 at 12:04 PM, Chris Jerdonek
wrote:
>
> On Sun, Oct 27, 2013 at 10:44 AM, Donald Stufft wrote:
>>
>> Here’s the list of dependency links for the projects that still use them in
>> their latest releases:
>>
>> https://gist.github.com/dstufft/7185162
>>
>> A good number of them
On Oct 27, 2013, at 5:49 PM, Chris Jerdonek wrote:
> On Sun, Oct 27, 2013 at 12:04 PM, Chris Jerdonek
> wrote:
>>
>> On Sun, Oct 27, 2013 at 10:44 AM, Donald Stufft wrote:
>>>
>>> Here’s the list of dependency links for the projects that still use them in
>>> their latest releases:
>>>
>>>
> So I asked the person I know, and this is what he said, "Yes, we have
> to use it! It's the only way to allow a package to install other
> packages that aren't on PyPI-- for instance, a custom fork of a
> library."
>
> Is there another approach or work-around he can be using? What is the
> "rig
Chris:
to be clear, after talking to Donald, we interpreted your question
differently.
- If you're distributing library Y, and it depends on X, but it now needs a
custom/fixed fork of X, then what Donald said, rename and re-publish (or
vendor it).
- If you just need to override a buggy pypi packa
On 28 Oct 2013 09:11, "Marcus Smith" wrote:
>
> Chris:
> to be clear, after talking to Donald, we interpreted your question
differently.
>
> - If you're distributing library Y, and it depends on X, but it now needs
a custom/fixed fork of X, then what Donald said, rename and re-publish (or
vendor
https://github.com/pypa/pip/pull/1264
On Oct 27, 2013, at 7:45 PM, Nick Coghlan wrote:
>
> On 28 Oct 2013 09:11, "Marcus Smith" wrote:
> >
> > Chris:
> > to be clear, after talking to Donald, we interpreted your question
> > differently.
> >
> > - If you're distributing library Y, and it dep
I have merged that PR but I really don't see any point in making any
changes to the current codebase beyond fixing significant issues. Cleaning
it up is not a priority. I've merged this PR to clean up the PyPI project
page on bitbucket a little, but I would ask that no further cosmetic PRs be
submi
Thanks.
Warehouse sounds very enterprisey. Any Roadmap for that, estimate time
to become operational? I'd need some features right now and not next
PyCon. Also, am I right that bus factor for this stuff is one?
--
anatoly t.
On Mon, Oct 28, 2013 at 2:53 AM, Richard Jones wrote:
> I have merged
I'm not sure what you mean by it sounding "enterprisey" except perhaps just
the name?
On 28 October 2013 10:58, anatoly techtonik wrote:
> Thanks.
>
> Warehouse sounds very enterprisey. Any Roadmap for that, estimate time
> to become operational? I'd need some features right now and not next
>
I mean that the name CheeseShop has more human touch in it than Warehouse.
--
anatoly t.
On Mon, Oct 28, 2013 at 3:00 AM, Richard Jones wrote:
> I'm not sure what you mean by it sounding "enterprisey" except perhaps just
> the name?
>
>
> On 28 October 2013 10:58, anatoly techtonik wrote:
>>
>>
Warehouse is the internal project name, and will be just one software component
of the service collectively known as PyPI. That said, Donald started it so by
law of the jungle he can call it whatever he wants as long as I don't get phone
calls from the FBI.
--Noah
On Oct 27, 2013, at 10:02 PM,
20 matches
Mail list logo
