I’m designing a semester-long programming course that’s going to utilize Github Classroom. It seems like the best workflow will be to have separate repos for each week’s content and assignment, so that’s 14 lesson repos, plus I was planning to have one “central” class repo, probably containing the lesson repos using git submodules.
Each lesson will have its own Project.toml, Mainfest.toml, docs and tests. My question is about registering all of these things. I will definitely register the Central repo, but how about the lessons? It seems excessive. Is this a good use-case for a “private” registry. I seem to remember some discussion on slack that other registries shouldn’t be used except in cases where things are truly private.
Students will use the github classroom interface for interacting with assignments (so I don’t need them to be able to ] add Assignment1), but I was wondering if it seems sensible to have a registered repo with a bunch of submodules that are not themselves registered.
1 Like
Can’t you just put everything in a single package, ask students to
pkg> add http://wherever.it/is
in the first class, and
pkg> up
from then on?
Not really. If I just wanted to give them code, sure, but the idea is that I’ll be giving them incomplete code that they have to finish and then commit. Plus, the github classroom interface actually has “assignment” infrastructure to keep track of which students have completed things by when to help with grading. Each assignment is a repo.
Besides, they’ll be learning git at the same time as julia, so the more they have to interact with actual repos rather than getting spoiled by Pkg the better 
Edit: I should mention, the registering is more for the julia community (in case someone else wants to do a similar course) than it is for students.
If by “registering” you mean registering to the General registry I don’t see any advantage to that. This is not even a package and nothing will depend on it.
This sems like spreading things out way too much. Just put the whole course in one repo, students git clone it and done. Each lesson in a subfolder, with a Project.toml, Mainfest.toml. Submodules are really a pain to work with as well.
1 Like
Yeah, this wouldn’t be the best workflow for a package/project generally, but I think it’s necessary for the github classroom integration,.
This is true. So maybe I shouldn’t register any part of it. That’s also on the table.
1 Like
But I would appreciate, if you put the link to it in the teching collection etherpad.
This seems like a perfectly valid use case for having your own local registry. As an experiment, I set up a public local registry for JuliaFinance and it is fine. The only catch is that there cannot be a package registered on General if it depends on a package registered in your local registry, but that doesn’t seem to be a concern in your case.
The advantage of a registry is:
- It allows for the resolver to find a set of dependencies that are compatible.
- It allows for assigning a name → package → url to download it so you can add things by name instead of URL.
None of these seems very useful here.
I can see merits in both approaches, but I would probably go with the approach outlined in the original post and that sounds more compatible with Git Classroom, i.e. one “central” course repo with its own Project.toml, Manifest.toml, docs and tests and then each lesson has its own repo with its own Project.toml, Manifest.toml, docs and tests. The central repo and each lesson repo can be registered in the local public registry set up specifically for this course.
I like this modular approach because it is much easier to revise, rollback, etc changes to any particular lesson. Unless you have significant Git kung fu skills, I wouldn’t know how to roll back a change to Lesson 5 without rolling back a change to all of the Lessons if they were all in the same repo. Presumably, if you put all the effort into preparing a course, you don’t plan to teach it just once so this would be easier to revise later on I think.
The good news is that all the functionality needed to make this happen is already there and working.
Submodules are really a pain to work with as well.
I agree. Stay away from submodules 
Project.toml and Manifest.toml are so much nicer 
Added, though the org is pretty bare bones at the moment
I think I agree.
Yeah, that’s been my experience too. I would not be asking students to use them. But in this case I think the central repo would just have links out to other repos. I can’t keep everything together, since github classroom expects separate repos for each “assignment”, and I really want to use their tooling to keep track of student work.
1 Like