Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Equinix Metal Python (via rename or new module) #106

Open
displague opened this issue Feb 19, 2021 · 5 comments
Open

Equinix Metal Python (via rename or new module) #106

displague opened this issue Feb 19, 2021 · 5 comments
Milestone

Comments

@displague
Copy link
Member

displague commented Feb 19, 2021

We would like to replace the use of the packet pypi module with a module that reflects Equinix Metal branding.
In doing so, we can not break existing projects that depend on thepacket package.

Outline the steps that will be taken to move this project ahead with an Equinix Metal focus.

Some questions to consider:

  • What is the name of the new module?
  • What reasons do we have to continue to offer this package as the primary Python package for Equinix Metal?
    • What are our alternatives? What drawbacks and benefits do these offer?
  • Does GitHub renaming this project create problems?
    • Or does creating a new GitHub project create problems?
    • In either case, how do users migrate between projects?
  • Can Pypi modules be renamed or aliased?
  • Is it sufficient for users to import packet as metal
  • How should environment variables be renamed, and how should legacy variables be honored?
  • What properties and functions need to be renamed (breaking compatibility with the packet package)
@displague
Copy link
Member Author

displague commented May 26, 2021

What are our alternatives? What drawbacks and benefits do these offer?

One alternative would be to use a generated client from the Equinix Metal API Spec:
https://github.com/displague/metal-python

This is my preferred approach but we need some investigation into how usable this client is.
We should be able to overcome any limitations through API spec improvements (including migrating to OpenAPI v3).

@pnhowe
Copy link
Contributor

pnhowe commented Aug 20, 2021

If you do rename the client, might I suggest python-metal, this more closely matches the naming use by packaging systems, ie: python3-werkzeug, https://pypi.org/project/python-twitter/, etc.
moving to a generated client would also save you some effort when the API changes, I have used https://swagger.io/docs/open-source-tools/swagger-codegen/ in the past and found it to work well enough for my needs.

@displague
Copy link
Member Author

https://peps.python.org/pep-0423/#overview has a section on namespacing (Top-level namespace).
Perhaps equinix-labs/equinix.metal or github.com/equinix-labs/python-equinix and pypi equinix (from equinix import metal)?

https://peps.python.org/pep-0423/#how-to-rename-a-project

@t0mk
Copy link
Contributor

t0mk commented Jan 5, 2023

@displague I like python-equinix best, but I think that if we generate Python SDKs from OpenAPI spec, we should keep separate packages per service (Metal, Fabric, Network Edge). So that new features in Fabric won't trigger version bump in a project that's using only Metal. Not sure if I explained that correctly. Also, it would be a bit messy to generate one Python package from more than one API docs.

I would go with python-equinixmetal, python-equinixedge, ...

@ctreatma
Copy link

The generated Python SDK is now at https://github.com/equinix-labs/metal-python, and as of v0.2.0 it has support for the full Equinix Metal API. We should deprecate this SDK in favor of that one, and add the appropriate notices in this project's README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants