-
-
Notifications
You must be signed in to change notification settings - Fork 14.6k
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
deeptools interferes with jupyter lab (problem with propagated inputs?) #261552
Comments
I think your are right, I can reproduce the issue. Do you have any more pointers to what's wrong? Is it mix of different python versions used by the tools and jupyter lab? Deeptools is a fairly complex build. I can try to upgrade the tool during the next day, maybe it helps? |
Sorry, I didn't see this: Really nice work, do you think this would fix the issue? |
Pre-commit is a weird case. I thought I fixed it with #235123 by making it more self-contained, but that caused other problems which I thought I fixed with #251418 which adds special cases in which it it it less self contained. I don't know deeptools well, but I somewhat doubt that the contents of #251418 are relevant to it (unless it somewhere has to call a program which is not expected to be packaged alongside it--that's what I broke). My impression is that deeptools contains utilities that are run as standalone progams. That is, like so: $ bamCoverage And not imported like a module: from deeptools import bamCoverage So the ideal case is that the executables that end up on the user's Since the deeptools derivation uses Perhaps this is obvious, but when I first encountered this kind of problem I benefitted from looking at the wrapper script which the problematic package generates:
So there they are, the packages which So the solution I'm suggesting is to change the derivation such that these dependencies stay in the wrapper script, but are not in the devShell. If you don't get around to it, I'll try to revisit this in a few weeks. Also, be aware that I'm not blocked by this. I have submitted that homework assignment and moved on. I just reported the issue because it felt like the helpful thing to do. It's possible that the real bug here is that I'm trying to use a devShell as a way to hack dependencies into a jupyter notebook in the first place. I've been meaning to study https://github.com/tweag/jupyenv, which likely provides a smarter way to do this. I just wanted to point this out because if you decided that this wasn't a bug after all, I wouldn't argue with you. |
Describe the bug
Jupyter Lab kernels fail to start, but only when deeptools is installed.
Steps To Reproduce
Here'a flake.nix
Steps to reproduce the behavior:
nix develop
jupyter lab
hi
Expected behavior
Jupyter Lab should work whether or not deeptools is installed
Logs
The jupyter labs logs do not exactly contain a smoking gun:
Additional context
I think that this problem is similar to the one solved here: #235123
Here is a workaround:
I can't be sure that
$out/nix-support/propagated-build-inputs
didn't break something, but the tool I need,bamCoverage
seems to work.Notify maintainers
@scalavision
Metadata
The text was updated successfully, but these errors were encountered: