My company was recently in this situation, and it was definitely hard to get information on non-self-hosted solutions for private packages. We settled on packagecloud.io, but there are some definite pain points that I think PyPA could productively document:
- Many tools do not support indices other than PyPI well. It is cumbersome and poorly documented to specify another index, and that index is only ever used as a fallback, increasing runtime and creating name-squatting concerns. - It is unclear which "python packaging" services actually offer a PyPI-like index, as opposed to an orthogonal Python library distribution strategy. - Packagecloud only supports the "simple" index API, which makes it slower for tools to work with and presumably less future-proof. It's particularly annoying to me, since I've been working on a dependency management system and only added support for PyPI's new JSON API. Having a quick survey of the options (including commercial ones) available and how tools integrate with them would have been very useful to us. On Tue, Jul 31, 2018 at 7:44 AM David Cournapeau <courn...@gmail.com> wrote: > > > On Tue, Jul 31, 2018 at 7:44 AM Nathaniel Smith <n...@pobox.com> wrote: > >> On Mon, Jul 30, 2018 at 3:13 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >> > On 30 July 2018 at 23:01, David Cournapeau <courn...@gmail.com> wrote: >> >> Hi, >> >> >> >> I see that there is almost no mention of private packages index in the >> >> packaging guide, and no recommendation on what to use. >> >> >> >> Currently googling for private packages mostly return obsolete (and >> not very >> >> practical) recommendations based on dependency links. >> >> >> >> In 2018, what would be the recommended practices for teams that develop >> >> private packages that depend on each other ? >> > >> > That's a very good point, and I think it would be a really useful >> > addition to the packaging guide. I believe the most commonly >> > recommended approach is to use a local,devpi instance as a private >> > index, but in terms of development workflow around that basis, I don't >> > really know that there's much in the way of a consensus. (I should say >> > that I don't work in an environment like this myself, so my comments >> > are based purely on what I've heard, not on personal experience). >> >> A tricky aspect here is that this niche has been colonized by >> commercial projects like Artifactory, Gemfury, etc., and I'm not sure >> we want to get into recommending one commercial product versus another >> (or that we even have any effective way to compare them). >> > > Right, I would not expect us to do anything besides maybe mentioning > proprietary solutions. > > But for OSS solutions, there are multiple options, and it is not clear > which ones are appropriate for which usage. E.g. do you need multi index > support, do you need upload support, etc. ? > > Would it make sense to start such a document as a PR ? > > David > > >> -n >> >> -- >> Nathaniel J. Smith -- https://vorpus.org >> > -- > Distutils-SIG mailing list -- distutils-sig@python.org > To unsubscribe send an email to distutils-sig-le...@python.org > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/7E3UF7J3TDVHG7DKBGJZF627D4JSDM7K/ >
-- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/4L62CFN6J5L24RGJTXN46U3IJ7HUPZTJ/
