search

wspace / corpus

The definitive collection of interpreters, compilers, and programs for the Whitespace programming language.
MIT License
30 stars 3 forks source link

Links to submodules from README.md are getting 404 #1

Closed hostilefork closed 3 years ago

hostilefork commented 3 years ago

The links are e.g.:

https://github.com/wspace/corpus/blob/main/rebol/hostilefork

That gives a 404. I'm not sure if GitHub has a good way to invariantly link to a submodule folder, as opposed to linking what it points to.

Perhaps GitHub could be lobbied to do the right redirect for such paths?

thaliaarchi commented 3 years ago

I've known about this issue for a while, but I left the links, reasoning that they're still useful for local usage.

I think there are three options for how GitHub could handle such URLs:

  1. Link to submodule repo URL at the specified commit (e.g. https://github.com/hostilefork/rebol-whitespacers/tree/4f88e715cc02f1aeb1ca8eeef98752ee54546cca). This loses track of the submodule location in the repo.
  2. Link to the containing directory (e.g. https://github.com/wspace/corpus/tree/main/rebol). This could place the user in a directory with many submodules, making it unclear which was intended (e.g. in python or javascript dirs).
  3. Link to a symlink-like page (URL would remain as present, e.g. https://github.com/wspace/corpus/blob/main/rebol/hostilefork). It would have a link to the submodule at the specified commit, but function similarly to how GitHub treats symlinks, i.e. in its own file.

I'll file a ticket (unless you want to) on GitHub Support since this particular issue hasn't been filed before. I suspect that response latency will be high due to vacations. For reference, it took 6 weeks before GitHub support got back to me about claiming the wspace organization name.

As for the table itself, it's very information-dense, so is difficult to navigate. I plan to generate an index in each language directory that provides more detail on each project, then I can remove some information from the main table. In the main table, I'll promote the submodule path (which functions as an ID since over half of the projects have generic names like "Whitespace Interpreter") to a column and remove the spec version and maybe the source code links to save space.

hostilefork commented 3 years ago

I'll let you post the proposal and then I'll chime in saying "yeah, this is important!" :-)

I like the idea of a page for the folder that gives you your bearing in the hierarchy of the project that has the submodule. Then you do another click to go to the target project.

(Especially since as I understand it a submodule could have some kind of link scheme that wouldn't be able to resolve to any page on the internet. So you'd want to be able to show something for these cases.)

thaliaarchi commented 3 years ago

Thinking about it more, it doesn't seem very useful to link to the submodules, even if there was a special symlink-like page. There's already a link to the source in the rightmost column.

What do you think of instead linking to the JSON data for the project? As an experiment, I split projects.json into small files per project, e.g. rebol/hostilefork.json for rebol/hostilefork. I'm still evaluating whether I like it and will keep it split. For now, projects.json is coexisting while I port the build scripts.

hostilefork commented 3 years ago

I'd think that ultimately what people would want out of the JSON would be a database they could ask questions of. In the nearer term a pretty-printed "summary" page for each project from a static site generator would be more useful than whether the source JSON is broken out. Anything that makes your maintenance harder is probably noise...

The first link that people come to left to right seems like it might be best to go to that pretty-printed summary page. Then make sure the project's homepage/source is the first big link on that summary.

thaliaarchi commented 3 years ago

I've updated the links to point to the JSON files, so this issue should be resolved.

As for generating summary pages for each project—that is a different issue. I haven't decided whether the summaries would be for browsing within the repo or a website. Since I just use the JSON files, I'm less motivated to design this and am prioritizing work on deterministic, automated builds and testing of each project.