Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Decide how to expose tools to users #5

Open
willGraham01 opened this issue Jun 16, 2023 · 6 comments
Open

[Feature] Decide how to expose tools to users #5

willGraham01 opened this issue Jun 16, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@willGraham01
Copy link
Collaborator

willGraham01 commented Jun 16, 2023

Is your feature request related to a problem? Please describe.
We should decide which, and how, to expose the various BrainGlobe tools included in the meta-package to users.

We should also document the new names/aliases of the tools.

Describe the solution you'd like
Users should be able to select the tool they wish to use from methods within the brainglobe namespace, which we can achieve in the manner described in Adam's comment here.

Describe alternatives you've considered
We could also expose all the (user-facing) sub-packages in __init__.py which has the advantage of not making the sub-package documentation redundant (until it relocates to the new website of course, when we can update our pointers accordingly).

brainglobe/__init__.py

import cellfinder-core as cellfinder
import brainreg

Then users would still have access to every public-facing tool, but the under-the-hood packages can remain hidden and we can reorganise them as we see fit.

import bg.cellfinder

# Do cellfinder things with bg.cellfinder, without ever worrying about cellfinder-core being there under-the-hood.
@willGraham01 willGraham01 added the enhancement New feature or request label Jun 16, 2023
@adamltyson
Copy link
Member

We should probably decide if we're going to keep the tool names (e.g. bg.cellfinder) or focus on application bg.cell_detector_3d), or both? I think I'm leaning towards application, because then this makes it easier to slowly build up a comprehensive toolbox of functionality, and organise repos as we see fit. Any thoughts @alessandrofelder?

@adamltyson
Copy link
Member

With the above, all the individual packages would be available anyway, so we wouldn't break any existing functionality.

@alessandrofelder
Copy link
Member

alessandrofelder commented Jun 16, 2023

I think I'm leaning towards application

If we go down this route, how would we organise the user documentation? Would it be confusing for users familiarising themselves with BG that what they know as bg.cell_detector_3d is actually cellfinder in disguise? For this, having a 1:1 correspondence between python package and naming in metapackage would be good?

@adamltyson
Copy link
Member

If we go down this route, how would we organise the user documentation? Would it be confusing for users familiarising themselves with BG that what they know as bg.cell_detector_3d is actually cellfinder in disguise? For this, having a 1:1 correspondence between python package and naming in metapackage would be good?

One idea would be to keep the docs as they are for a while while we build the metapackage (and a napari meta-plugin?). Then one day we release "BrainGlobe 2", which includes the introduction of the new structure. In most cases it would just be a case of bulk renaming of docs and UI elements.

We could make the naming in the metapackage match the napari plugin fairly easily. not sure if we'd want to rename the packages though.

Not sure if this is a good idea, just putting it out there because once we make a decision, we should stick to it.

@alessandrofelder
Copy link
Member

alessandrofelder commented Jun 16, 2023

Think I'm leaning towards keeping the original names (but consolidating cellfinder-napari and cellfinder-core into one repo etc.) because I expect our users recognise them already and so will have a smoother switch to the metapackage, and things only ever have one name?

@adamltyson
Copy link
Member

Think I'm leaning towards keeping the original names (but consolidating cellfinder-napari and cellfinder-core into one) because I expect our users recognise them already and so will have a smoother switch to the metapackage, and things only ever have one name?

Sounds good to me. I think I'm convinced. No reason why we can't have bg.cellfinder and bg.some_new_thing_that_doesnt_need_its_own_name coexisting too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants