Create a Python package to avoid overriding sys.lib in the code about docker-registry HOT 7 CLOSED

I am willing to do this work. Should we have any discussion before I begin?

One simple question is what the namespace should be. I suggest "docker.registry" as a natural, predictable namespace. from docker.registry.storage import Storage for example. Or if you want to keep this distinct from the "docker" namespace, you could choose "docker_registry", as in from docker_registry.storage import Storage. That's a bit more cumbersome to type though. :)

I am very interested in doing this because I would also like to add (as a separate effort of course) the use of python entry points for loading 3rd-party storage backends. That isn't possible without making the registry a python package.

from docker-registry.

I'll run through a few benefits just to help support the RFE:

• The install process already steers you toward making a virtualenv in which to install dependencies, so it is a natural next step to install the registry the same way.
• A huge benefit of having the registry on the python path is that other projects can use it, import it, and extend it. For example, "from docker.registry.storage import Storage", then make a subclass.
• Another benefit is that it makes packaging for an OS easier.
• Manipulating sys.path is risky, and it could cause OS distributions to be hesitant about including docker-registry. However, making an rpm/deb/whatever from a standard python package is very straight-forward and a common/well-understood process.

from docker-registry.

On Fri, Mar 21, 2014 at 12:45:31PM -0700, Michael Hrivnak wrote:

One simple question is what the namespace should be. I suggest
"docker.registry" as a natural, predictable namespace. from docker.registry.storage import Storage for example. Or if you want
to keep this distinct from the "docker" namespace, you could choose
"docker_registry", as in from docker_registry.storage import Storage.

I'm not a maintainer, but my personal preference is for
docker_registry, to force a clear distinction between this server-side
stuff and the the client-side docker package 1. We also avoid the
namespace package shenanigans needed to graft the registry code onto
an existing (or not?) docker-py install [2,3].

from docker-registry.

On Fri, Mar 21, 2014 at 12:45:31PM -0700, Michael Hrivnak wrote:

I am willing to do this work. Should we have any discussion before I
begin?

Also, as I pointed out earlier 1, this restructuring would conflict
with my outstanding #247. A restructuring PR in parallel with #247
would be possible, but a bit awkward, and I'd like to minimize the
overlap period while both are cooking. I'm happy if that's by merging
#247 before starting on this, or by doing this restructuring and
landing it quickly, after which I can rebase #247. I just don't want
both a restructuring and #247 to drag on through multiple future
iterations before one of them lands.

from docker-registry.

docker-py does indeed already have the docker namespace, so I'm going with docker_registry.

I've already done most of the work of moving things around, and all the tests pass. Now I just need to hand-test running it, and update things like build.sh and Dockerfile. So I should be able to submit a PR in the near future, and hopefully it won't require too much back-and-forth in the review process. :)

So @wking , I am hopeful that the restructure will be done very soon. I think it won't be difficult to rebase, as I've left the structure within each module alone. Everything in lib looks the same, everything in storage looks the same, etc. Just the import statements are different.

from docker-registry.

Now that #297 is landed, future releases should get pushed to PyPI and
we can close this issue.

from docker-registry.

We can now close the oldest registry issue \o/

https://pypi.python.org/pypi?%3Aaction=search&term=docker-registry-&submit=search

from docker-registry.