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

Re-consider use of pins to encourage leaving dependencies unpinned #24

Open
3 tasks
consideRatio opened this issue Feb 14, 2023 · 2 comments
Open
3 tasks

Comments

@consideRatio
Copy link
Member

We have pins to the patch version in our environment.yml file, and when users clone that and make changes, I think that sets a bad precedence for them.

I've maintained docker images for several years, and having things pinned and not pinned has pro's and con's, but I'm a firm believer that we and people cloning this repo will end up benefiting from not pinning dependencies overall.

Action point

Indicate disagreement or agreement to take the action of unpinning the following dependencies entirely

  • jupyter_contrib_nbextensions==0.5.1
  • jupyterhub-singleuser>=3.0,<4.0
  • nbgitpuller=1.1.*

- jupyter_contrib_nbextensions==0.5.1
# Required until https://github.com/jupyterhub/repo2docker/pull/1196 is merged
- jupyterhub-singleuser>=3.0,<4.0
# Set default python version to 3.10 - repo2docker sets it to 3.7 instead by default,
# which can limit us to older package versions
- python=3.10
# Everyone wants to use nbgitpuller for everything, so let's do that
- nbgitpuller=1.1.*

@yuvipanda
Copy link
Member

#11 is pretty relevant too.

I think we have to have some control over jupyterhub-singleuser and nbgitpuller, and the default python version on repo2docker was far too old. Perhaps one way to deal with this is to specify minimum required versions here rather than pin as we have?

@damianavila
Copy link
Contributor

I think we have to have some control over jupyterhub-singleuser and nbgitpuller, and the default python version on repo2docker was far too old. Perhaps

I concur about maintaining control of some specific packages (like the ones mentioned by @yuvipanda). For any others, let'em fly free, IMHO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Needs Shaping / Refinement
Development

No branches or pull requests

3 participants