search

cmelab / polybinder

Initialization of thermoplastic polymer systems to simulate thermal welding
GNU General Public License v3.0
2 stars 5 forks source link

The utils directory isn't added when installing uli-init via the .yml file #38

Closed chrisjonesBSU closed 3 years ago

chrisjonesBSU commented 3 years ago

When creating the environment using environment-nohoomd.yml there is an error when trying to import uli-init. The error stems from the __init__.py file.

from . import utils

When you look in the location of uli_init within the conda environment path there is not a utils directory. There are compounds and forcefields though.

I'm not sure if this is related to something in the setup.py file as to why utils isn't making it over during install.

chrisjonesBSU commented 3 years ago

Kind of related as well, but while I can understand the importance of using pinned versions of uli-init when creating images that will be pulled and used on clusters, it creates kind of a problem when wanting to install from source and make any sort of changes to the code.

Right now, both .yml files install a tagged uli-init within the conda environment path. If someone wants to do some development work do they have to edit and remove the line that installs a tagged version of uli-init, then run pip install -e .? Should there be a 3rd environment file? I'm not quite sure where conflicts arise with changing the .yml files and building the containers.

chrisjonesBSU commented 3 years ago

Looks like the issue is because the utils directory doesn't have an __init__.py file?

chrisjonesBSU commented 3 years ago

Looks like the issue is because the utils directory doesn't have an __init__.py file?

This didn't solve the problem for me.

/home/chris/miniconda3/envs/uli-init/lib/python3.7/site-packages/uli_init

Still only shows the following contents:

compounds  forcefields  __init__.py  __pycache__  simulate.py  __version__.py

So, from . import utils in the __init__.py file throws an error.

chrisjonesBSU commented 3 years ago

Kind of related as well, but while I can understand the importance of using pinned versions of uli-init when creating images that will be pulled and used on clusters, it creates kind of a problem when wanting to install from source and make any sort of changes to the code.

Right now, both .yml files install a tagged uli-init within the conda environment path. If someone wants to do some development work do they have to edit and remove the line that installs a tagged version of uli-init, then run pip install -e .? Should there be a 3rd environment file? I'm not quite sure where conflicts arise with changing the .yml files and building the containers.

Running pip install -e . from within the repo will override the conda installation of the tagged version, so this should be an easy enough solution to that.