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

20 fix cyclic import #21

Merged
merged 7 commits into from
Jan 11, 2024
Merged

20 fix cyclic import #21

merged 7 commits into from
Jan 11, 2024

Conversation

tomarnepedersen
Copy link
Collaborator

No description provided.

tomarnepedersen and others added 6 commits January 10, 2024 15:23
…n. Created the sphinx api docs using a manual call to sphinx-apidoc instead:

sphinx-apidoc -f -e -M -o docs src/trafficgen
…form of index.rst) already existed in the repo. Having both would be one toctree too many. Further, created api.rst to move all API documentation into its own sub-folder in the documentation.
Copy link
Contributor

@ClaasRostock ClaasRostock left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi Tom Arne @tomarnepedersen,

I see you you now have gone back to using the local import statements (i.e. from .module1 import Class1).
I assume this likely is because id otherwise did not work in your environment?

If so, then what is missing is that the shell process in which you work does not know where to search for the trafficgen package you ask for when importing with from trafficgen.module1 import Class1.

This is not exactly a fault. In fact it is a design feature. It avoids that tests run on GitHub (or with .tox on your local machine) find your package source code. You want good tests to run on - and only on - the installed version of your package. If it is installed, then it will find it. If it is not installed, it will not find it and fail. And that is what you want.

The backdraw of that self-discipline is that neither you, developing in your local environment, can find your package.
But there is a solution: If you create file in your workspace root named .env, this will by default be read by the shell process.
In that .env file, you can specify any variables you want to be 'on-the-fly' added to your USER environment.

In your particular case, try to write the following text in the .env file:

PROJ_DIR=C:\\GRD\\Maritime\\github\\ship-traffic-generator
PYTHONPATH=${PROJ_DIR}\\src

With that, your Python process should be able to find the trafficgen package when it encounters a line saying from trafficgen.module1 import Class1

This way you can use a clean way of writing imports (i.e. not local imports, but global) AND at the same time have the comfort of a still working development environment.

If you like, try it. Otherwise of course you are free to merge with the local imports as currently used :-) !

@tomarnepedersen tomarnepedersen merged commit c20c2e3 into main Jan 11, 2024
12 checks passed
@tomarnepedersen tomarnepedersen deleted the 20_fix_cyclic_import branch January 11, 2024 10:12
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

Successfully merging this pull request may close these issues.

2 participants