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

Translator Modulification #63

Open
crankynetman opened this issue Nov 4, 2024 · 0 comments
Open

Translator Modulification #63

crankynetman opened this issue Nov 4, 2024 · 0 comments

Comments

@crankynetman
Copy link
Collaborator

crankynetman commented Nov 4, 2024

Right now the translator isn't setup properly as a python module. This makes doing stuff with pytest REALLY difficult, and it'd be nice to have this be setup as a proper module with init.py, and the likes.

During the solving of this, it would also be nice to come up with a better way to generate the gobgp python client. Right now all the files are generated when the container is built and then stored in the same directory as the translator.py and gobgp.py files. This has a few downsides:

  • Breaks Intellisense/Code completion and other IDE tools that rely on being able to fully analyse the code (pylint/flake8 on save for example)
  • You can't easily run the code outside of the container (because the deps are not copied back out in any way)
  • You cant really run the code outside of translator.py even within the container because of dependencies and imports and other goofiness.

This work would, in my mind, involve:

  • Taking the translator code and turn it into a proper python module using whatever the current Right Way® is in python that you're supposed to use for doing that these days (i.e. not setup.py anymore I think).
  • Figuring out a way to actually package up the gobgp library into something that we can have available locally and inside the container.
    • Maybe we do this by copying the files around? I tried this a bit but with mounting them, it gets a bit crazy.
    • Maybe we generate these files by Some Process® and have them checked-into the repo. They Shouldn't Change® unless we bump the GoBGP version anyways, so re-building them every time the way we do isn't really necessary.
    • Figure out how other people fit this into their docker workflows. Surely someone has solved this.
  • Maybe we even want to take this opportunity to separate the translator code/container into a separate repo and combine with with breaking apart the docker compose stuff from the actual code stuff?
  • Potentially considering how a user might add translators to SCRAM without having to update the main repo and make a pull request, etc. (this might be early optimization though)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

1 participant