Renames part 1 - Githubissues

jeffhhk commented 3 years ago

Based on discussion today, I think it’s probably best to do this change in more than PR piece. I’ve prepared the first PR piece along the lines of things we covered today:

move biolink/ to medikanren/
move “contributed” things to contrib/
move truly bitrotted things to attic/

jeffhhk commented 3 years ago

@gregr Sounds good. Done

jeffhhk commented 3 years ago

After you're happy with the PR but before you merge it, I am happy to squash the double moves. But when I force push to update, I'm not sure that all your comments will stay intact.

gregr commented 3 years ago

Thanks, squashing will be good.

@webyrd do you want to take a look at the new directory structure before the mass-movement of files? This is the best time to object to any of these choices. Everything is moving somewhere new.

The last thing I'm on the fence about is whether medikanren[2] should be something simpler, like v1 and v2. What do you all think?

namin commented 3 years ago

Because the repo is already called mediKanren, I have a slight preference for v1 and v2, as otherwise, you have mediKanren/mediKanren which will be a pain.

gregr commented 3 years ago

Yeah, I agree with @namin .

jeffhhk commented 3 years ago

I did think about the mediKanren/medikanren path. Here is my rationale for what I chose:

The repository name is "mediKanren" but the directory inside is "medikanren". So barring cloning into a nonstandard location, the K case tells you which thing you are looking at.
I have started to find myself repetitively saying "biolink(1)" to distinguish from the biolink2 directory, so I totally get that it sometimes feels weird for one of two directories to have a number.
When we get info.rkt metadata, building a package called "medikanren1" would be awkward. Packages already have version numbers. Building a package "medikanren" from a directory "medikanren1" also seems odd.
I think it's important to get out of the "forking for versioning" pattern. Having two versions in one tree is a reasonable hack when you know the version 2 is going to be a long lived branch while version 1 is essentially still under development. But when version 2 is done, a maintenance branch can represent the state of things for 1.0 stability, and that's much more sane than starting a directory for version 3. Delete serves a very useful purpose in a versioned system by directing attention toward current practice.

My preference is for the medikanren/medikanren2 scheme. But if others feel strongly I'm happy to go with medikanren1/medikanren2.

gregr commented 3 years ago

Oh, I didn't realize you were planning to turn this into an actual Racket package. What would be the benefit of doing so? Will it make development more complicated?

webyrd commented 3 years ago

Looks good to me!

jeffhhk commented 3 years ago

Minutes ago I realized there is a one time heads up about this change.

Minutes ago I realized there really is a “heads up” message that needs to accompany PR #53 being on master. Directories don’t exist in git. Only files. And so biolink/data and biolink2/data are totally out of git’s purview. And config.scm files are not changed tracked, by design.

So once you merge or pull, if you don’t do this you will be confused:

mv biolink/data medikanren/data
mv biolink2/data medikanren2/data
mv biolink/config.scm medikanren/
mv biolink2/config.scm medikanren2/

It's a one time thing.

webyrd / mediKanren

Renames part 1 #53