search

rapidsai / jupyterlab-nvdashboard

A JupyterLab extension for displaying dashboards of GPU usage.
BSD 3-Clause "New" or "Revised" License
598 stars 78 forks source link

Conda Releases #56

Closed quasiben closed 4 years ago

quasiben commented 4 years ago

We need new conda releases on rapidsai-nightly and conda-forge. Latest conda releases are 0.1.11

jakirkham commented 4 years ago

On rapidsai, it is up-to-date.

Not sure how rapidsai-nightly is updated. Maybe someone from OPS can comment (cc @raydouglass)? 🙂

The jupyterlab-nvdashboard feedstock has PRs open to update. So it is just a matter of someone working to integrate those.

raydouglass commented 4 years ago

I've released a v0.3.0 nightly to rapidsai-nightly, pypi, and npm.

owenlamont commented 4 years ago

Hi @raydouglass - sorry I tried to jump in and work on the conda-forge PR but I hadn't properly checked the other issues here until now. I didn't know there was a rapidsai conda channel and I also see the meta.yaml in this repo which I didn't try to keep consistent with my PR. I guess conda-forge recipes work differently but I assume the requirements should be consistent between both?

Happy to help if I can and I'm not getting in your way. Is the rapidsai channel meta.yaml the one included in this repository?

raydouglass commented 4 years ago

Is the rapidsai channel meta.yaml the one included in this repository?

Yes, that's correct.

owenlamont commented 4 years ago

Hi @raydouglass, @jakirkham - I ran into an issue with my conda-forge recipe and I was wondering if you can advise on the best way to resolve it. Unlike the rapidsai recipe the conda-forge recipe meta.yaml automatically installs the labextension. That is nice but the issue is that the recipe explicitly sets the version number of the labextension to match that of the conda package.

That is problematic because if you install version 0.3.1 of the conda package the labextension will be broken if the user is using jupyterlab 1. I see two possible options and I was wondering which you both think is better:

  1. I remove the explicit labextension version number from the conda-forge meta.yaml and trust the labextension to install the highest version supported by the jupyter lab the user has installed (that is how it works now with the rapidsai recipe - except the user has to manually install the labextension).
  2. I explicitly restrict the conda-forge recipe to require jupyterlab >=2 (which is what I currently have in my PR) and maybe I need to add a seperate conda-forge recipe for version 0.3.0 which has a jupyterlab <2 requirement.

I'm not sure what you think is better or whether there is some other options I'm overlooking.

owenlamont commented 4 years ago

I've done a bit of research into how other jupyter lab extension python packages install and keep their node packages in sync. I found the following packages install their lab extensions automatically:

Interestingly I couldn't find any other lab extensions that call jupyter labextension install from their meta.yml or associated scripts. I guess they wanted a way that isn't restricted just to conda recipes - I don't know if there's any other reason not to do that. I haven't thoroughly looked but most seem to implement the lab extension install in their setup.py logic.

Looks like a relatively big job and the topic for a different issue and PR.

jakirkham commented 4 years ago

Yeah I asked about this once in issue ( https://github.com/conda-forge/ipympl-feedstock/issues/26 ). It sounded like people weren't sure whether this should be done generally. Perhaps it would be worthwhile to revisit that discussion?

jacobtomlinson commented 4 years ago

For the record, I'm happy to remove the jupyter labextension install from the recipe. It was an experiment to see if it was possible more than anything.

owenlamont commented 4 years ago

Interesting discussion on the ipympl feedstock. I do like the convenience of conda installing the labextension itself. I hadn't thought about the complexity of multiple kernels in different environments though (I usually always use local environment kernels). I've left the labextension install step in the conda-forge recipe for now... but happy to go with the consensus if anyone wants to change that.

jakirkham commented 4 years ago

Leaving it seems fine to me, but no strong feelings.

owenlamont commented 4 years ago

The conda-feedstock is updated now so we can close this issue I think...

jakirkham commented 4 years ago

Thanks @owenlamont! 😀

jakirkham commented 4 years ago

FWIW there is some discussion about updating how JupyterLab extension Conda packages are built in issue ( https://github.com/conda-forge/conda-forge.github.io/issues/761 ). This includes both general changes that are suggested as well as changes for JupyterLab 3.