Skip to content
This repository has been archived by the owner on Jul 2, 2022. It is now read-only.

If path is now in spork, deprecate this repo? #6

Open
uvtc opened this issue Mar 21, 2021 · 6 comments
Open

If path is now in spork, deprecate this repo? #6

uvtc opened this issue Mar 21, 2021 · 6 comments

Comments

@uvtc
Copy link
Contributor

uvtc commented Mar 21, 2021

Now that path is in spork, all changes to path should go there, correct?

Other than updating the readme here, does github provide a way to mark a repo as deprecated/moved?

@pepe
Copy link
Member

pepe commented Mar 22, 2021

Yes, I think spork/path is the thing now. And I think you can archive the repo and maybe remove it from the pkgs.

@uvtc
Copy link
Contributor Author

uvtc commented May 29, 2022

I think it would be less confusing if, once a module is moved into spork, its old repo is either removed or else marked in some way as deprecated (maybe a first line in the readme).

@sogaiu
Copy link

sogaiu commented May 29, 2022

Currently, I don't think removal is nice to code that depends on the thing being removed.

For example, if I have code that depends on path in its own repository and I don't know about thte transition, I think that can lead to breakage. If I'm the maintainer of that code and the sole user, it might be an adjustment that is doable, but what about the case where I'm not the maintainer and just a user?

@bakpakin
Copy link
Member

Yes, this is why these repos are not removed, although I don't recommend using them. Perhaps enough time has passed to remove them

@sogaiu
Copy link

sogaiu commented May 29, 2022

Don't know about feasibility, but I wonder if there could be some way to signal to folks that something might be absorbed elsewhere in the future -- possibly with some indication of time-to-such-an-event. Somewhat like deprecation?

@uvtc
Copy link
Contributor Author

uvtc commented May 30, 2022

@sogaiu , I was just thinking the same thing. If we could use Janet's own deprecation mechanism, such that, when you import this path module, and then run your code, you get a warning on the command line,

"The path module you're using has been replaced by spork/path. To avoid issues down the road,
please consider migrating to spork/path."

Given that changes like this often happen in the free and open source software world, I think such a mechanism would be generally very useful.

I'm not yet familiar with usage of Janet's deprecation facilities. Would be much appreciated if someone could post an example to, say, the forum (or a link to a blog post), detailing how one can mark their module in this way (so it gives a warning when you import it).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants