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 <[email protected]> wrote: > > > On Tue, Jul 31, 2018 at 7:44 AM Nathaniel Smith <[email protected]> wrote: > >> On Mon, Jul 30, 2018 at 3:13 PM, Paul Moore <[email protected]> wrote: >> > On 30 July 2018 at 23:01, David Cournapeau <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ > Message archived at > https://mail.python.org/mm3/archives/list/[email protected]/message/7E3UF7J3TDVHG7DKBGJZF627D4JSDM7K/ >
-- Distutils-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/4L62CFN6J5L24RGJTXN46U3IJ7HUPZTJ/
