On 31 July 2018 at 08:13, Paul Moore <p.f.moore@gmail.com> wrote:
On 30 July 2018 at 23:01, David Cournapeau <cournape@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).
Ah, I thought we already had something on this: https://packaging.python.org/guides/index-mirrors-and-caches/ That emphasises the devpi caching proxy use case though, and doesn't point out that devpi is actually a full-fledged private Python package repository manager that's still lightweight enough to run locally as a caching proxy: https://devpi.net/docs/devpi/devpi/stable/%2Bd/index.html So even with that page, there's likely value in adding a second guide called something like "Running a private index server" that covers the options from "Just use a simple static file server", through to a Python specific package management engine like devpi, and on to open source multi-format repository management systems like Pulp and the various commercial options (I don't think we should be overly averse to mentioning those - we're mentioning commercial deployment platforms in the packaging overview, and honestly, there are a lot of folks out there where one of the professional lessons they're still learning is "your time as a developer is expensive, so you typically don't want to build what you can already buy"). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia