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

remove duplicated packages from requirements.txt #3

Merged
merged 1 commit into from
Aug 11, 2021
Merged

remove duplicated packages from requirements.txt #3

merged 1 commit into from
Aug 11, 2021

Conversation

JILPulvino
Copy link
Contributor

No description provided.

@github-actions
Copy link

Binder 👈 Test his PR on Binder

@JILPulvino JILPulvino merged commit e822aea into 2i2c-org:main Aug 11, 2021
@JILPulvino
Copy link
Contributor Author

@yuvipanda @sgibson91 I made some changes to the requirements.txt, that I thought would clear up the following issue, but it's persisting. When I made my initial pull request yesterday, the image built successfully on binder. But when I changed the image tag in the Configurator and load a new server, the added packages are not available on the hub, despite a supposed successful build. I changed the requirements.txt to remove a couple of lines where packages were repeated and submitted a new pull request. On binder, this image builds successfully - though it does at the end say 'failed to connect to event stream' rather than loading the image. Despite this 'successful' build, again in the jupyterhub, after replacing the docker tag in the Configurator, the packages in requirements.txt are not available in the hub.

Any clue what may be happening?

@sgibson91
Copy link
Member

the packages in requirements.txt are not available in the hub

Did you restart the user server?

though it does at the end say 'failed to connect to event stream'

This is more to do with JavaScript running in the browser than it is about successful builds. Most likely, your pod was up and running in the cluster but something prevented the browser redirect. A couple of things you can try here is just refreshing (you should immediately see "Found built image") and making sure ad-blockers are not active on mybinder.org (they can interfere).

@JILPulvino
Copy link
Contributor Author

thank you @sgibson91. The second issue was an ad blocker.

I did restart the server and just tried it again and same problem. I try to load the altair package in a notebook or in the python console and it states that the module can't be found.

@yuvipanda
Copy link
Member

@JILPulvino hmm, so the mybinder link (from #3 (comment)) doesn't have a working altair either, so at least it's not specific to the hub

@JILPulvino
Copy link
Contributor Author

Ahh, I didn't think to test in the binder, was just ensuring that the build was correct.

@sgibson91
Copy link
Member

Maybe an environment.yaml file and installing via conda will help? https://altair-viz.github.io/getting_started/installation.html

@yuvipanda
Copy link
Member

@sgibson91 there's a Dockerfile here already that brings in common packages from the pangeo images. I just opened #4 which stops inheriting from the pangeo image, and just uses repo2docker. This means we'll have to explicitly list all the packages we want - but that's probably ok?

@JILPulvino
Copy link
Contributor Author

Would there be an issue if we moved to using a environments.yml file to compile instead as well? We are looking to use such a file in some of our other repos to take advantage of conda being able to specify R packages and environments. This also goes to @damianavila question about generalizing.

@yuvipanda
Copy link
Member

@JILPulvino absolutely, you can just use an environment.yml file instead. Just remove the Dockerfile and add an environment.yml file, and test it out on Binder with the button the bot gives you

@2i2c-org 2i2c-org deleted a comment from yuvipanda Aug 13, 2021
@damianavila
Copy link

(deleted a dupe comment from Yuvi ⬆️ )

Rethinking this one, as I said in the PR, I agree about going from simple to complex.
The requirements/environment file solution should be enough OK for now and if more complexity is needed later, a Dockerfile with the "proper" parent can be introduced in the future.

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.

4 participants