First “public” release. Tested only very roughly. But as this is hardly a mission-critical service, using it is not very risky.
Worst case scenario if thins break: You lose the index and automtic installation won’t work anymore. Assuming you keep your package sources around, you’ll be safe.
Note that this is currently not meant to be a persistent storage for your packages. If the project evolves (specifically the database and database migrations), this may change.
To get started the only two pieces of information you need is the installation, and configuration. Here you go:
mypi is a “personal” package index for Python packages. By default, it’s possible to publish packages to the main python package index (a.k.a. “cheeseshop”). But this list is public by default. Sometimes you cannot or don’t want to put packages on the public index. This is what mypi is for.
Here are some situations where this may be true:
But why would you even want to bother with a package index at all. The main reasons are:
You want a central authoritative repository for all deployed applications, without publishing to the world.
You want to be able to use pip to install packages
When typing pip install yourpackage it will search a specific package index (by default pypi.python.org) for yourpackage. If found, it will try to find the newest release (unless otherwise specified), download and install it.
So if your package is not published on pypi, you won’t be able to use pip. With mypi, this is possible.
You want to be able to add your private packages to package dependencies.
Similar to the pip command, package dependencies rely on an authoritative site like pypi to be able to search for the packages. If your packages are registered on mypi, dependency retrievel will be automatic.
The python package managers (pip, easy_install) both allow you to specify URLs where you can package releases. They simply open these URLs and search for links matching package names.
djangopypi actually is implementing pretty much the same ideas as mypi. So instead of listing advantages/disadvantages, I am only going to list the major differences:
To give you an idea what this project is about, i’ll list my decisions for this project including their “state”.
mypi should:
... be easy to install [good enough for now (could be improved)]
... run in a virtualenv [works]
... be well documented [should be okay (you’re reading it...)]
... make it possible for package maintainers to upload packages via python setup.py sdist upload [OK]
... allow easy_install my_package or pip install my_package. [OK] (see Index Configuration)
... not necessarily require logins/passwords when uploading. This could be added later on but is not of biggest importance.
Rationale: In our current environment network access is restricted using a firewall. So authentication is not strictly necessary. This is dogfood-ware. I am writing this for myself, and I am practising YAGNI. If I see that there is a real demand for this feature, and if I find the spare time, I might go ahead and implement it. For now, it’s of no high importance though.
Note
For people that need this, this chould in theory be solved with WSGI middleware if really required until it’s built-in.
As a starting point: http://stackoverflow.com/questions/723856/wsgi-authentication-homegrown-authkit-openid
In order to use a custom package index in python, you need to configure pip, easy_install and python as needed.
See Index Configuration for more details.