[BGV1] Updates to `brainreg-segment`

[willGraham01]

Subtask of #33.

brainglobe/brainreg-segment

• [x] Update name to brainglobe-segmentation
  • [x] Update pyproject and other dependent files
  • [x] Update other dependent packages
  • [x] Check PyPI and conda are OK with the name change, then publish version

OLD TASKS (pre brainglobe-registration)

• Update with "final version" release. Stage as a PR against main.
  • Point users to brainreg repository as replacement
  • Point users to the blog post for more information
  • Tagged version should be <v1.0
  • Push to PyPI
• Depreciate package on PyPI
• Archive repository

[adamltyson]

brainglobe/brainreg-segment

Should this be brainglobe-napari?

[adamltyson]

I know see that https://github.com/brainglobe/BrainGlobe/issues/37 exists, so I guess this issue is about brainreg-segment. Did we decide to merge brainreg-segment into brainreg?

[willGraham01]

Yeah it's in the master issue for the new release (#33): we'll have brainreg as one package with core, segment, and napari submodules (the latter two being optionals).

The issue is more for my own sanity so I don't have to X-reference with #33 every time I tick a task off.

[adamltyson]

I'm leaning towards not merging brainreg-segment into brainreg, as it, or something like it should be compatible with the new brainglobe-registration plugin.

[willGraham01]

I'm leaning towards not merging brainreg-segment into brainreg, as it, or something like it should be compatible with the new brainglobe-registration plugin.

Our counterargument for merging it in was that in it's current state, its only use is tied to post-processing for whatever comes out of brainreg (or similar - I can search my notes for the exact thought process / reasons).

I'd be inclined to stick to the merge plan because it reduces the number of repos we have under the brainglobe name, and (even if it is compatible with upcoming brainglobe-registration) is still going to be fundamentally tied to brainreg anyway.

brainreg-segment and brainglobe-registration are both eventually going to end up under the brainglobe-meta umbrella I presume, in which case I'd also prefer to bundle all of brainreg together. Or if this is a case of a historical naming convention, maybe we change the name so it's not so implicitly linked to brainreg?

[adamltyson]

The eventual new version shouldn't be tied to brainreg. I'd rather keep it unbundled and with the same name for now. Once it's compatible with brainglobe-registration it can be called brainglobe-segmentation or something.

I think when we decided to merge, we didn't have a concrete plan for the development of brainglobe-registration.

[adamltyson]

We could just rename it to brainglobe-segmentation now?

[willGraham01]

I think when we decided to merge, we didn't have a concrete plan for the development of brainglobe-registration.

:thumbs_up: No problem (I did make the plan ~2 months ago so things are bound to have changed!).

We could just rename it to brainglobe-segmentation now?

I'll convert this issue / open a new one to do this. Renaming right now may break some things that depend on (or look for) brainreg-segment. Also I'll need to check what PyPI (hence conda) thinks about renaming.

[willGraham01]

We could just rename it to brainglobe-segmentation now?

Looks like there's a standard method for renaming on PyPI, although we do have to retire the old repository. I'm guessing we don't want to retire brainreg-segment as a repository due to it's GH metrics @adamltyson ?

The (quite hacky) alternatives I can think of would be:

• Publish a final release of brainreg-segment marking the package as decprecated and directing users to brainglobe-segment (which as of yet does not exist, but we'll combat that in a second).
• Rename the repository to brainglobe-segmentation and update the package metadata in a PR
• Merge the PR in, and publish a new release v1.

Slightly cleaner hack:

• Rename the brainreg-segment repo brainglobe-segmentation
• Fork/clone the (now) brainglobe-segmentation repository, calling it brainreg-segment. We'd need to make sure we also preserve release notes and tags.
• Publish a release from (new) brainreg-segment marking depreciation etc. Then archive this fork/clone repo immediately.
• Publish the "new" brainglobe-segmentation package.

Slightly cleaner hack is "cleaner" because it means we won't break any of our existing dependencies on brainreg-segment as it'll continue to exist whilst we update everything else. Unless anyone objects, I'll go with this approach.

[adamltyson]

I think I prefer the first option, mostly because it reduces the number of repos we have and retains GH metrics etc. Also, it won't be a new tool, for now it's literally just a renaming.

[adamltyson]

Also, importantly it will mean that links (e.g in the paper) will redirect.

[willGraham01]

Also, importantly it will mean that links (e.g in the paper) will redirect.

I wasn't aware GitHub did this :thinking: So if I rename brainglobe/brainreg-segment to brainglobe/brainglobe-segmentation, both of the following links will direct me to the same (renamed) repository?

• Use the old link
• Use the new link

[adamltyson]

I assume so, if you move a repo between orgs, it will redirect.

[willGraham01]

Will pop back here and check in any case, once all the merging is done!