New package: RemoteREPLNG v1.0.0

[JuliaRegistrator]

• Registering package: RemoteREPLNG
• Repository: https://github.com/GenieFramework/RemoteREPLNG.jl
• Created by: @essenciary
• Version: v1.0.0
• Commit: 70830ba1a8f17645c15d355eb8a64592427e3d5b
• Reviewed by: @essenciary
• Reference: GenieFramework/SuperRemoteREPLNextGenForTheCommonGood.jl@70830ba#commitcomment-171511518
• Description: Connect a REPL to a remote Julia process

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines which are not met ❌

• I was not able to load the package (i.e. import RemoteREPLNG failed). See the AutoMerge logs for details.
• Package name similar to 1 existing package.
  1. Similar to RemoteREPL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.

3. Needs action: here's what to do next

1. Please try to update your package to conform to these guidelines. The General registry's README has an FAQ that can help figure out how to do so.
2. After you have fixed the AutoMerge issues, simply retrigger Registrator, the same way you did in the initial registration. This will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless the AutoMerge issue is that you skipped a version number).

If you need help fixing the AutoMerge issues, or want your pull request to be manually merged instead, please post a comment explaining what you need help with or why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the public Julia Slack for better visibility.

4. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

Why couldn’t this be contributed to RemoteREPL.jl?

Forks of registered packages are usually only registrable under the rarest circumstances

[essenciary]

Because that package seems abandoned and I don't have time/patience. There are issues opened without follow ups (breakages since Julia 11.5). And right now, it's completely incompatible with Julia 1.12 and nobody even bothered to extend the compat for dependencies.

Please do not transform package registration into gatekeeping, especially if package maintainers don't want to manage the codebases anymore.

[essenciary]

[noblock]

[essenciary]

Additionally, I think that the "similar name" rule is doing a disservice to the community. I want to fork and maintain and grow a cvasi-abandoned package. I think the correct thing is to still reference the original package, both as credit to the original creator (I kept the author/contributors) and as help for the users that might want to use a newer package. I could give it a completely different name and remove all traces to the original, but I think that would be dishonest and would not serve anybody.
[noblock]

[goerz]

Please do not transform package registration into gatekeeping

I'm sorry, but the General registry is a limited shared resource. Managing that involves at least some gatekeeping, and there is wide consensus that the General registry should be lightly moderated.

especially if package maintainers don't want to manage the codebases anymore.

We have procedures for that: adding new maintainers, potentially even without the involvement of existing maintainers if they cannot be reached. The original RemoteREPL package is already part of the JuliaWeb organization, and there should be active members/owners of that org you that should be able to help with this. @c42f seems to have been pretty active with RemoteREPL, so maybe she can help you with getting your contributions merged?

I don't have time/patience

That is not a good basis for contributing packages to General. If your motivation is acting "for the common good" (#143493) then engaging with existing contributors instead of registering forks is the proper way to go. I understand that can involve some frustration and takes more energy and time, but it greatly strengthens the Julia ecosystem as a whole

[essenciary]

Please understand that while software creators are "encouraged" to wait for weeks to grease the wheels of dead packages, free and paying users of our Julia software can't use our app on Julia 1.12. As a community, we need to take a more agile approach towards supporting users and creators in the Julia ecosystem.

I just want to have a working package that doesn't break our product so that I can solve our user's problem.

[goerz]

As far as I'm concerned, the correct solution to this problem is to give you commit access to the existing RemoteREPL. That's assuming the package doesn't have sufficient active maintainers who can merge PRs in a timely fashion

[essenciary]

I agree but that is usually a pretty lengthy process. I took my time to review the state of the project (issues, PRs), and given that issues have not been answered since spring, I decided to take the different route.

[MasonProtter]

I understand your frustration here @essenciary, but IMO taking it out on Michael is not fair or productive.

It really does not need to be a lengthy process to get you a commit bit (ideally it'll be quicker than the 3-day waiting period for new packages). RemoteREPL.jl is under the JuliaWeb organization, so it's likely an option to just add you.

Unfortunately I don't have permission to give you commit access to RemoteREPL, but I can merge PRs. If you submit your changes as a PR, I'd be happy to try and review and merge it.

[essenciary]

taking it out on Michael is not fair or productive

I did not do that. I just raised some points in a public discussion that I'm hoping will be taken into account and considered by people taking these decisions.

If we want the Julia ecosystem to grow, we need more agile practices to support quick updates of production/commercial software. Production software can see many releases per day. Waiting days for package approval and weeks/months for issues to be reviewed (or ignored in this case), is not the way to go.

OK, I will submit the PR, of course. Thank you.

[MasonProtter]

I fixed up and merged Morten's PR here: JuliaWeb/RemoteREPL.jl#77 (I missed it when it was published before, got buried in my Github notifications) and a new version of RemoteREPL which runs on v1.12 (and nightly) should be registered in the next half hour or so (ref: #143502)

I had to mark one of the completion tests as broken for now just to get this unblocked, but I'll open an issue about that and then we can see what needs to be done to get that completion item working properly.

[goerz]

taking it out on Michael is not fair or productive

I did not do that

No worries, I did not feel like anything was taken out on me.

I understand that the friction of ecosystem maintenance can cause some frustrations, and there can also be differences of opinion, like

I think that the "similar name" rule is doing a disservice to the community.

If we want the Julia ecosystem to grow, we need more agile practices to support quick updates of production/commercial software.

The processes we have are generally deliberative and based on consensus among the registry maintainers (and ideally the wider community). We're taking a middle road between free-for-all like NPM and PyPI and extremely curated ecosystems like CRAN, with some amount of "collective ownership"; and definitely not a "move fast and break things" approach.

There is always room for evolving opinions and further discussion, but those are probably best done on Discourse (like the recent discussion about registering vibe-coded packages).

I just want to have a working package that doesn't break our product so that I can solve our user's problem.

Not necessarily what should to happen here, but for critical components especially of a commercial product, vendoring it (copying it into your codebase as a submodule) can be worthwhile

[noblock]

[ericphanson]

Please understand that while software creators are "encouraged" to wait for weeks to grease the wheels of dead packages, free and paying users of our Julia software can't use our app on Julia 1.12. As a community, we need to take a more agile approach towards supporting users and creators in the Julia ecosystem.

I just want to have a working package that doesn't break our product so that I can solve our user's problem.

sounds like maybe you need your own registry? then you can have your customers use it and make whatever packages/releases you want without spamming General (#143493)

General is only special in that its pre-installed, but otherwise custom registries have full support in Pkg, and there's tooling like https://github.com/GunnarFarneback/LocalRegistry.jl to help as well.

Your users would do pkg> registry add $registry_url and then after that they can access packages from that registry as usual.

[essenciary]

@MasonProtter thank you for the quick turnaround

@goerz I'm of the opinion of allowing free registration with the market sending quality signals. It's not like people blindly install packages by tab-tab-ing their way in the pkg> repl. I understand that this is a decision for the wider community, but I'm sure these things come up from time to time, as I can't be the only one getting stuck in these threads.

Thanks, I did consider vendoring myself, but git submodules are a bit of a pain.

Finally, I was considering sourcing the github URL of my fork directly in Project.toml but that's only for Julia >= 1.11 which opened a new can of worms (diverging codebases with distinct releases for pre and post Julia 1.11).

Overall, I remain of the opinion that package registration is a major source of anxiety and friction (for me at least, it always is). In addition, with multiple ways of doing things (per above), maybe some official documentation of best practices for how to handle such situations, from somebody more versed than me in these topics, might be very useful.

Thanks again for the kind support.

[essenciary]

@ericphanson yet another excellent alternative, thanks

[JamesWrigley]

@essenciary, I've sent you an invite to the repo.

[essenciary]

@JamesWrigley Thank you, accepted. Happy to be part of the team!

[JamesWrigley]

BTW, in general I would not be afraid of outright asking for maintainer privileges for packages 🙂 Either to the maintainers directly or some other channel like Slack/Discourse/Zulip depending on where the contributors are (e.g. #web on Slack in this case). In my experience lots of folks are quite willing to give access as long as you have a good track record, and at the very least they'll become aware that you're open to that responsibility which is good if there comes a point that they'd like to step back.

In this case where the package is part of an organization, also feel free to ping other members of the organization directly if you're not getting replies. Speaking for myself, even though I'm a member of the org and get notifications for package activity I'll most likely ignore them if I'm not actually a maintainer of the package in question, just because I'm likely not familiar with it and have not gotten permission from the original maintainer to merge things.

[essenciary]

Thank you all for the quick fixes and the kind support, RemoteREPL now works as expected on Julia 1.12 and the patch fixes downstream dependents. 💜

[goerz]

Closing as completed 😀