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

Manage/set dependencies versions #607

Closed
2 tasks done
gcroci2 opened this issue Jun 6, 2024 · 2 comments · Fixed by #616
Closed
2 tasks done

Manage/set dependencies versions #607

gcroci2 opened this issue Jun 6, 2024 · 2 comments · Fixed by #616
Assignees
Labels
CI continuous integration

Comments

@gcroci2
Copy link
Collaborator

gcroci2 commented Jun 6, 2024

Given that active development on this project slowed down, we need to make the dependencies more reliable in terms of version used during the installation, including in the CI. The easiest way to go consists in just fixing dependency versions. However, it's good to try to avoid falling too far behind and encountering security issues.

I suggest:

  • To create a requirements file after having re-installed everything in a brand new env, to be sure we are up-to-date with the latest versions working of the various packages (pip freeze > requirements.txt); We know that these versions work for sure.
  • Fix versions for critical dependencies (e.g., PyTorch) and use version ranges for less critical ones (e.g., numpy).

I think it's good to first fix #559 (dropping entirely the conda thing) and then go for this one.

@DaniBodor
Copy link
Collaborator

Maybe part of this could also be to work with a single env file. The only difference I think is that the docker calls a separate file to install the local package. If there's a way to do this outside the env file, then we can get by with a single one.

(or is this part of #559)?

@gcroci2
Copy link
Collaborator Author

gcroci2 commented Jun 10, 2024

Maybe part of this could also be to work with a single env file. The only difference I think is that the docker calls a separate file to install the local package. If there's a way to do this outside the env file, then we can get by with a single one.

(or is this part of #559)?

Yeah I think this is part of #559, we will look into this possibility there

@gcroci2 gcroci2 removed the blocked label Jun 20, 2024
@gcroci2 gcroci2 self-assigned this Jun 20, 2024
@gcroci2 gcroci2 linked a pull request Jun 20, 2024 that will close this issue
@gcroci2 gcroci2 closed this as completed Jul 9, 2024
@gcroci2 gcroci2 moved this to Done in Development Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI continuous integration
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants