This is a great idea. Also I want to point out that:
1. Sometimes it's OK to start by sharing a repo on Git{Hub Lab}. Not
everything needs to go on pkgs.racket-lang.org immediately, to be
visible and share, especially early on.
(To be clear, I'm not saying, "oh only perfect 1.0 things should be a
package". I'm just pointing out that pkgs.r-l.org isn't fantastic for
discoverability, so if that's the main motivation, it's not your only
or even your best option.)
2. If you do have a package that does XYZ, and someone then makes a
package for X, sometimes it's OK to change your package just to
re-`provide` their module for X (and yours still does Y and Z).
For example, my rackjure package had a threading macro. Then Alexis
made a `threading` package. It was 99% compatible, she took a PR for
the 1%, and I changed rackjure to re-provide that. And the docs say
so. So, it didn't break users of rackjure. Plus people could switch to
using `threading` directly, if/when they wanted. And the Racket world
had one less bit of duplicate code. I think that worked out well.
(In fact if that continued to where rackjure was "merely" a
"meta-package" that re-provided focused packages, I'd be fine with
that!)
Maybe that idea could apply here?
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
