search

greenelab / GCB535

Materials for GCB535 at Penn.
BSD 3-Clause "New" or "Revised" License
20 stars 8 forks source link

Student's Computational Environment #161

Open gwaybio opened 6 years ago

gwaybio commented 6 years ago

It appears that setting up a custom conda environment for students is more complicated than I initially thought. See #155 for details leading up to this issue.

The folks at cocalc have been responsive to my support ticket and I have gotten permission from them to post their responses below.

Summary

To summarize, it appears that we have a couple of options:

tagging @cgreene and @bvoight for discussions/decisions - thanks!

CoCalc Ticket:

My Initial Question

  1. We are interested in creating custom jupyter kernels with conda environments. We have successfully created a custom Jupyter kernel using these instructions https://github.com/sagemathinc/cocalc/wiki/Programming#anaconda-jupyter.
  2. Our goal is to perpetuate this environment to students, but it seems this is not done automatically.
  3. Is there functionality to define a custom kernel, send to students, and be able to update between assignments? We have discussed this issue in some amount of detail here: https://github.com/greenelab/GCB535/issues/155

First Response

Hello, there is currently no automatic way to share data between a teacher's project and the one of students. So, unfortunately, It's a no for 2. and 3. As you have experienced, teacher projects and student projects are rather independent. However, one avenue you can take is to define the directory where the kernel is as a "handout" in a course file. Then, when you send out the handout, this directory will be copied over to all students. I don't know what your kernel consists of, so maybe this isn't enough. Another way would be to host a setup file and share instructions with your students how to install it. I'm imagining a bash-script, that's run like wget | bash in a terminal. Well, I also read your ticket on github. Sending out a whole anaconda environment to all students might be necessary, although I think that's a bit fragile. Well, I read that you're also suggesting to ask us to install some packages. Of course, we could try to do that, too.

Second Response

I think "course handouts" almost already completely solves 1-3, except that ~/.local can't be a handout right now since it starts with a dot. If we have a way to make handouts that start with dot, then their 1-3 is easy -- just push out a subdir of ~/.local. Can you do a quick test yourselves to understand what I mean?

  1. Create a .course
  2. Create a handout in some path ~/foo
  3. Push it out
  4. Observe that ~/foo is created in all student projects The second problem for you is that you would want updating -- i.e., repushing the handout -- to not make backup copies of files. For that we could (and should) add an option. Under the hood, handouts are just "rsync this same directory to all course projects". We could make handouts work with directories that start with a dot, and also add an option to control how re-pushing the handout behaves. This would take some effort, and I don't want to allocate time to it right now unless it is something that you think will definitely solve your problem. You can also definitely repost what either of us wrote here.
gwaybio commented 6 years ago

Given the short time frame, I am leaning more towards option 1 for 2018. We will at least have a working product this way

cgreene commented 6 years ago

If the .local approach is a 10 minute fix for them, then we'd love to do it that way. If it's not going to be ready (realistically) today, then I think we should do option 1. With the work that you've already done, we should be able to ask them for the latest versions of the relevant packages that you've dug up.

cgreene commented 6 years ago

Either way, communicating the strong desire for the .local option is probably helpful for next year :)

cgreene commented 6 years ago

@gwaygenomics What did you decide on this? Wondering how we should triage the issues you have for the 2018 Milestone.

gwaybio commented 6 years ago

yeah... add to 2019 milestone. I requested the .local feature to the cocalc admin and I think they are working on it.

I reverted the first couple modules back to python (sagemath) kernel, but there are more I need to revert back (from python (GCB535)). @kelsj and I need to make sure we don't push out notebooks with this kernel - they cause errors that could be pretty confusing

cgreene commented 6 years ago

Ok - can you update the milestones for whichever issues are affected?

cgreene commented 5 years ago

I sent a new ticket to catch up on this. It's #6071 in zendesk for them. I'll update when I hear more.

We corresponded with you last year about this. Some of your responses are tracked in this github issue: https://github.com/greenelab/GCB535/issues/161

I'm curious whether or not you've had a chance to implement a solution that would help us push an environment out to the students.

Thanks! Casey

cgreene commented 5 years ago

A feature that could help has been added. We could modify the first assignment to include the code necessary to setup the environment: https://doc.cocalc.com/teaching-tips_and_tricks.html#run-terminal-command-in-all-student-projects

Here is the full reply:

Hi, Casey.

We don't have specific support for e.g. distributing custom kernels in ~/.local. But we have added a feature that may help. If you use Handouts to distribute files, you can then run a command to move/copy/etc. in each student project. Please see "Run Terminal command in all student projects" in the User Manual: https://doc.cocalc.com/teaching-tips_and_tricks.html#run-terminal-command-in-all-student-projects

Hope this helps.

Hal