Decide on what to do with `jaraco.*` projects

[bswck]

A number of projects lands in the jaraco/ directory of site-packages/ during installation:		downloads last month	jaraco's role	uses skeleton?
jaraco.classes	40009617	Owner
jaraco.functools	1695144	Owner
jaraco.collections	873666	Owner
jaraco.text	855839	Owner
jaraco.context	778832	Owner
jaraco.logging	34133	Owner
jaraco.stream	21597	Owner
jaraco.itertools	7966	Owner
jaraco.env	6257	Owner
jaraco.path	4119	Owner
jaraco.envs	3813	Owner
jaraco.email	3717	Owner
jaraco.versioning	3631	Owner
jaraco.packaging	3562	Owner
jaraco.abode	3494	Owner
jaraco.docker	3134	Owner
jaraco.ui	3123	Owner	❌
jaraco.windows	3024	Owner
jaraco.structures	2770	Owner
jaraco.develop	2470	Owner
jaraco.net	2259	Owner
jaraco.vcs	1989	Owner
jaraco.mongodb	758	Owner
jaraco.services	430	Owner
jaraco.clipboard	379	Owner	❌
jaraco.test	376	Owner
jaraco.tidelift	297	Owner
jaraco.fabric	277	Owner
jaraco.xonsh	211	Owner
jaraco.pmxbot	196	Owner
jaraco.util	194	Owner
jaraco.postgres	188	Owner	❌
jaraco.financial	153	Owner
jaraco.apt	129	Owner	❌
jaraco.timing	124	Owner	❌
jaraco.modb	119	Owner
jaraco.crypto	116	Owner
jaraco.home	107	Owner
jaraco.site	76	Owner
jaraco.compat	68	Owner	❌
jaraco.nxt	64	Owner
jaraco.video	60	Owner	❌
jaraco.media	54	Owner
jaraco.geo	54	Owner
jaraco.xkcd	48	Owner	❌
jaraco.zstd	42	Owner
jaraco.translate	34	Owner	❌
jaraco.input	29	Owner	❌
jaraco.keyring	28	Owner	❌
jaraco.office	26	Owner	❌
jaraco.imaging	23	Owner	❌
jaraco.parables	16	Owner	❌

_{(Table generated with jaraco_namespace.py).}

Should we (and how) change the namespace of these? @jaraco

[bswck]

jaraco.develop and jaraco.site can be surely excluded from the list. Assuming we migrate to coherent.*, some could be renamed on the way, e.g. jaraco.envs→coherent.venvs (a better distinction from coherent.env). Some packages could be checked if they should be actually maintained by Coherent OSS, especially those that don't use skeleton or their last release was before 2023:

	downloads last month	jaraco's role	uses skeleton?
jaraco.stream	21597	Owner
jaraco.docker	3134	Owner
jaraco.ui	3123	Owner	❌
jaraco.clipboard	379	Owner	❌
jaraco.test	376	Owner
jaraco.postgres	188	Owner	❌
jaraco.apt	129	Owner	❌
jaraco.timing	124	Owner	❌
jaraco.compat	68	Owner	❌
jaraco.video	60	Owner	❌
jaraco.media	54	Owner
jaraco.xkcd	48	Owner	❌
jaraco.translate	34	Owner	❌
jaraco.input	29	Owner	❌
jaraco.keyring	28	Owner	❌
jaraco.office	26	Owner	❌
jaraco.imaging	23	Owner	❌
jaraco.parables	16	Owner	❌

For each of these, let's determine whether they are still going to be maintained or not.

[bswck]

jaraco.stream, jaraco.docker and jaraco.ui got quite a bit of downloads last month, so I guess Coherent OSS should continue maintaining it. As for the rest, I'm concerned the migration might be an unnecessary hassle.

[jaraco]

Hmm. I hadn't planned on renaming the projects or their namespace anytime soon. My instinct was to start with:

• Host the jaraco.* projects under coherent without rename.
• So, jaraco/jaraco.collections would move to coherent-oss/jaraco.collections and would still install jaraco.collections.

This approach would allow the projects to be maintained by the organization and benefit from the uniformity of settings that can be applied at the organization level (settings relating to auto-merge, etc) and simplify custodial matters relating to bus factor and collaboration.

I was not planning to migrate anything to coherent.* yet. I'd probably start by creating the next new thing under coherent.* but not migrate anything right away. I'd want to make sure the name has legs and doesn't run into any conflicts or disputes before forcing a transition on users and downstream packagers (I'm thinking about Linux package managers and my former Google colleagues and the toil they would endure simply by migrating half a dozen packages).

For each of these, let's determine whether they are still going to be maintained or not.

My instinct is that anything that's likely to get a release anytime in the future should probably be migrated. Even if it's very personal (like jaraco.develop mostly is), it's still beneficial to share the custody of it, even if other members of coherent-oss would be largely uninterested in maintaining it. There would be no obligation to host it and the repo would likely get archived or turned down on my demise, but otherwise it would operate more or less as it had under my personal account.

There are maybe a handful of these that I might recommend for archival now (jaraco.office, jaraco.geo, jaraco.compat come to mind), and thus could be excluded, but I'd recommend if they're going to be excluded, let's archive them first and thus exclude archived repos from migration.

I'm genuinely surprised how many of those aren't using skeleton. My suspicion is that they are using skeleton, but I just haven't had the need or desire to cut a release. For example, jaraco.parables has been synced with skeleton 2024, but is so stable that it doesn't have a release in PyPI. It probably deserves a release in PyPI just to update the badge and other best practices. On the other hand, that library was extracted from pmxbot, so maybe it makes sense to migrate it to the pmxbot org (with or without a rename). Since I was looking at it, I cut a release just to give it a refresh.

All that said, I don't want to sully the name of coherent-oss by littering it with a bunch of junk. On the other hand, I do want the barrier to entry for any contribution to be incredibly low. jaraco.docker is 12 lines of code that gives StackOverflow users an easy answer to a rather mundane but impactful question.

I'm happy to adjust to your expectations. Feel free to propose a different approach, but here's what I recommend:

• migrate everything that's maintained supported (unarchived)
• be prepared to migrate back anything that turns out to be a nuisance

Let me know what you think.

[bswck]

Thanks!

I'm happy to adjust to your expectations. Feel free to propose a different approach, but here's what I recommend:

• migrate everything that's maintained supported (unarchived)
• be prepared to migrate back anything that turns out to be a nuisance

Let me know what you think.

I really like that empirical approach, it will be the most optimal for your and my time. As everything is clear now, I'll close this as completed and jump on #3.