-
Notifications
You must be signed in to change notification settings - Fork 3
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
Conversation
…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.
There was a problem hiding this 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 :-) !
No description provided.