Using namespace package to inject 3rd party plugins. Is it a good idea?

Python Help
1

Let’s say there’s a public package foobar that I do not own. I want to write a 3rd party plugin for it such that the usage is:

pip install foobar-myplugin

from foobar.plugins.myplugin import SuperFooBar

Would it be problematic if I use the namespace package foobar? Understandably I open myself to conflicts if the foobar author ever uses the foobar.plugins namespace. However that can be remediated by just asking them to reserve this for 3rd party.

I don’t often see this pattern. More often I see package source code repos contains an aggregation of all plugins (e.g., Django contrib, Airflow providers) or the package provides some API for registering plugins (hatch, pytest)

2

You can only do this if they are already using foobar as a namespace package. If they are doing that, it’s probably fine, but you should still talk with them.

If they aren’t using foobar as a namespace package, you can’t install yours because it would be conflicting non-namespace packages and one of the two would take priority.

2 Likes
3

Thank you! That pretty much convince me I shouldn’t be doing this.

I’m open to alternatives if you’ve any. In the meantime, I guess I must use a different root-level import name (e.g., import foobar_myplugin).

4

I recall a very similar question being asked quite recently but can’t find it right now… maybe it was on another forum. Anyway…

What has been said above about the names of the import packages is true.

Now for the name of the distribution package:

If you are keto and they are foobar, the practice is that you should not create projects whose name start with foobar unless they (foobar) agreed to it. Typically projects/organizations want to own their own prefix. So I believe what you can and probably should do is name your project something like keto-foobar. This might even be enforced at PyPI level in the future if this brand new PEP gets accepted: https://discuss.python.org/t/pep-752-package-repository-namespaces/61227.

1 Like
5

Thanks @sinoroc. This question was indeed motivated by PEP 752. I’m seeing a future where there are shared distribution prefixes/suffixes in the name, but do not share import/package namespace.

pip install google-cloud-storage  
# Google allows 3rd party to use distribution prefix: google-cloud-storage-
pip install google-cloud-storage-awesome
  • Scenario 1: Google does not allow 3rd party use of namespace package
    # Google does not allow 3rd party to use package namespace
from google.cloud.storage import Client
from google_cloud_storage_awesome import AwesomeSauce
  • Scenario 2: Google does allow 3rd party use of namespace package
    # Google does allow 3rd party to use package namespace
from google.cloud.storage import Client
from google.cloud.storage.awesome import AwesomeSauce
6

The intention of the PEP (if I read it correctly) is that the foobar organization will take ownership of the foobar- name prefix but will be able to open the foobar-ext- name prefix to the community. In that case you would be allowed to take ownership of the name foobar-ext-keto.

But on the other hand we also have the convention that the distribution package name should match the import package name. So according to this convention your import package should be one of:

  • import foobar.ext.keto
    • this assumes foobar.ext is a namespace package (which implies foobar is one as well)
  • import foobar.ext_keto
    • this assumes foobar is a namespace package
  • import foobar_ext.keto
    • this assumes foobar_ext is a namespace package
  • import foobar_ext_keto
    • no namespace package needed