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

Installing Courses #166

Open
thinkmorestupidless opened this issue Mar 16, 2022 · 3 comments
Open

Installing Courses #166

thinkmorestupidless opened this issue Mar 16, 2022 · 3 comments

Comments

@thinkmorestupidless
Copy link
Contributor

thinkmorestupidless commented Mar 16, 2022

Overview

Currently, when executing any of the cmtc commands it's necessary to pass a "studentified repo" path which points to where the command will be executed.

This requires, of course, for the studentified version of a course to be present on the machine where the command is being executed.

What if the studentified version of the course could be downloaded automatically by the course management tools?

What if, once it has been downloaded, the course could be set as the default target for the cmtc commands?

Implementation

What is proposed, then, is for the addition of 'package management' operations for the course management tools:

Install

The install command would allow a user to specify the course to be downloaded and have the course management tools automatically get the course from wherever it is hosted and place it on the local machine.

This leads to two questions:

  1. Where are the courses stored remotely?
  2. Where is the downloaded course stored locally?

In an initial implementation i propose to have courses stored in Github repositories and use git clone to download the files (allowing for them to be easily kept up-to-date).

So, the install command could just provide the username/project convention, for example:

cmtc install thinkmorestupidless/studentified-test

Would clone the thinkmorestupidless/studentified-test repository into some local location... where?

Following the conventions of other tools it would make sense to have the notion of a CMT_HOME directory which defaults to ~/.cmt

In ~/.cmt would be located a *.conf file which can store any global configuration necessary for the tool operations (which can be loaded when the tool is executed) and a ~/.cmt/courses sub-directory could store the courses themselves...

Giving this layout:

Screenshot 2022-03-16 at 08 39 46

Context

Once a course has been installed we need to be able to tell the course management tools which course in the ~/.cmt/courses directory we want to have the course management tools operate on (that is, which course to talk to when we issue next-exercise, pull-solution, etc)

By have *-context commands we can have the course management tools write to a the ~/.cmt/cmt.conf file and read from that file to set a current-context property which points to the location of the course we want to operate on.

set-context

So, for example:

cmtc set-context studentified-test

would result in ~/.cmt/cmt.conf looking like:

cmt {
  current-context: "~/.cmt/courses/thinkmorestupidless/studentified-test"
}

We can then load ~/.cmt/cmt.conf when the cmtc is executed and have the context available as a default (which could also be overloaded if a path is supplied by any of the cmtc commands.

# executes on the course specified in `cmt.current-context`
cmtc next-exercise

# executes on the course located at /my-course
cmtc next-exercise /my-course

get-context

To know the current context (which course i'm currently using) we can then add cmtc get-context which will just print the value of cmt.current-context to the screen

cmtc get-context
>> /Users/trevorburtonmccreadie/.cmt/courses/thinkmorestupidless/studentified-test
@thinkmorestupidless
Copy link
Contributor Author

I'm not sure about using the term context here - in the draft of this issue i'm using context because it's what's used in, e.g. Kubernetes for the context currently being acted upon.

Does it make sense to use context here, too?

Could it, for example be set-current-course/get-current-course or is that sacrificing brevity for a slightly clearer terminology?

Alternatively a course sub-command that has the "package management" command within it... so

# installs course from foo/bar Github repository
cmtc course install foo/bar

# sets current course to `~/.cmt/courses/foo/bar`
cmtc course current bar

# prints '/Users/trevorburtonmccreadie/.cmt/courses/thinkmorestupidless/studentified-test'
cmtc course current

@thinkmorestupidless
Copy link
Contributor Author

Installing courses into a sub-directory of the hidden ~/.cmt directory is going to cause problems for anyone trying to load the course into an IDE. The default /courses directory should be somewhere public e.g. ~/Documents/Courses or something similar?

@eloots eloots transferred this issue from eloots/cmt-2 May 13, 2022
@thinkmorestupidless
Copy link
Contributor Author

thinkmorestupidless commented Apr 19, 2023

Here's the logic for the install command following on from our last discussion:

The install command is used like this:

cmtc install path/to/thing

And, we're going to support 3 types of thing to install

  1. A course in a local directory
  2. A course in a zip file in the local file system
  3. A course in a Github repository

This means parsing path/to/thing and:

  • if it ends in .zip and it exists then we're using method (2)
  • if it's a directory and it exists in the local file system we're using method (1)
  • If it's none of the above then check if it's a Github project, if so we're using method (3)

Installing from a local directory is just a case of copying the directory (recursively) to the ~/courses directory (and then setting it as the current course)

Installing from a zip file involves:

  • unzipping the file to a temp directory
  • checking it's a valid cmt course (TODO: how to do this?)
  • if it's a valid course, copy it to ~/courses and set it as the current course
  • delete the temp directory

Installing from a Github project involves:

  • listing the releases for the project
  • finding the latest release
  • downloading the release artifact that matches the project name (optionally including -student in the zip file name)
  • at this point we follow the steps for installing from a zip file

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

No branches or pull requests

1 participant