Feature request: refactor so code is downloaded to process.cwd() instead of ~/src

[atrnh]

Summary

Change dmget's behavior so it downloads code to the current working directory instead of ~/src.

Open questions

Why download to ~/src to begin with?

dmget downloads to the static location, ~/src—it inherited this behavior from its ancestor, hbget over at Hackbright.

IIRC, I think hbget only uses ~/src because we had students using Virtual Box VMs and that's the directory that'd get mounted to the VM. Don't quote me on that though.

❓ Risk to curriculum stability

Thankfully, curriculum ain't that stable yet 🚀 ...but it is important to keep in mind that changing the behavior of a central tool will inevitably introduce wonkiness to instructions.

How can we ensure that as few bugs make it to students as possible?

❓ Prior art + adhering to current CLI design expectations

Might be a good opportunity to think about how UX devX should work.

• ls w/o arguments will list files in cwd, ls <path> will list files in <path> (cd behaves similarly)
  • should dmget work similarly?
    • might need to split this into another issue though 😆

❓ Why change anything?

What's bad about the way things work at the moment?

• What problems are we encountering/observing?
• How widespread are the problems?
• How severe are the problems?

Notes

Besides that changing behavior will inevitably break instructions 😬

This should probably do it 👇

src/constants.mjs

- export const DESTINATION = join(homedir(), "src");
+ export const DESTINATION = process.cwd();

[jared-at-devmountain]

I don't have a problem with dmget itself. But I would like it to be used more consistently: in fact, I'd like it to be used for every demo, demo solution, lab, and lab solution.

Right now, I feel that I can't depend on it very much. For example, sometimes when I download a demo dmget, I'm expecting an uncompleted project, but I instead get the completed project (solution). In that case, I have to create the uncompleted project myself, create a zip file, and share it with students. I'd love to ever have to make a zip file for a lecture again. For another example: in some cases I believe, the lab isn't downloaded from dmget. That inconsistency is confusing for students.

[jared-at-devmountain]

But I don't see any need to modify its behavior. I think the costs of that change wouldn't outweigh the payouts.

[atrnh]

Right now, I feel that I can't depend on it very much. For example, sometimes when I download a demo dmget, I'm expecting an uncompleted project, but I instead get the completed project (solution). In that case, I have to create the uncompleted project myself, create a zip file, and share it with students. I'd love to ever have to make a zip file for a lecture again. For another example: in some cases I believe, the lab isn't downloaded from dmget. That inconsistency is confusing for students.

I totally remember feeling this pain as a lecturer @jared-at-devmountain 💀

This is actually another quirk we just inherited from Hackbright's legacy curriculum build system. Under that build system, there's no way to create separate starter code and solution code packages for lectures (https://github.com/DevMountain/foundations and https://github.com/hackbrightacademy/swe-curriculum still use this build system).

https://github.com/DevMountain/webdev-curriculum uses a newer system, so we're totally free to have separate starter/solution ZIPs 😮❗

[atrnh]

Also, this already exists:

dmget/index.mjs

Line 117 in f038c1f

.option("-p, --path <destination>", "path to extract files", DESTINATION)

[kylebaugh]

I really like the idea of changing it to download to a current directory. Having it go to one place doesn't allow for much reusability. It also makes it harder to find specific source code when it's all in one file. If we used the current working directory, it allows for more structure of the content (week1 folder, week2 folder, week2-day3 folder, etc). It would also give them more experience doing file navigation in the terminal.

[suthyscott]

I wholeheartedly second Kyle's points. I think this would be a big quality of life change for staff and students as well as provide
a lot of beneficial terminal navigation and organization practice to students.

[seanthewonderful]

My 2¢ is to agree with Kyle's original request also.

• Downloading into the current working directory seems the most intuitive.
• I believe this will also significantly improve students' ability to navigate from the command line.
• Currently, lots of students just copy+paste the cd command anyway (CL expertise does not increase with using dmget).
• Several students manually move all the dmget files into a custom directory anyway.
• Many students also just use the download link so they don't have to use dmget at all.

[agprett]

I want to echo Kyle's points as well. Another potential benefit with an update is on the first day of class when we talk about the terminal and git, if we help them set up a file structure we can get more hands on with the demonstration of how to use the terminal. We can use commands we know will work because we know what folders and files they have which is all lost if the students just need a src folder.

There is also some quality of life for us as staff from an update. I redownload each lab and demo every cohort so I can have a fresh copy to work through with students. In order to get the new copy I would either have to move or delete the copy I had previously used. That was the big reason why I altered my download in the first place.

[Diegopie]

Just adding my support to Kyle's comment. Having that default behavior of downloading to the current directory will help students and staff keep things organized.

I currently teach the mv command to download to the src and then move it to a file structure. Though most students either manually move things in their file explorer or just deal with a messy src folder