brainglobe / brainglobe-workflows

Workflows that utilise BrainGlobe tools to perform data analysis and visualisation.
BSD 3-Clause "New" or "Revised" License
9 stars 2 forks source link

Add hard dependency on brainglobe-meta package #72

Closed willGraham01 closed 5 months ago

willGraham01 commented 5 months ago

See https://github.com/brainglobe/BrainGlobe/issues/33 | This should be the final task in the list, so it actually closes https://github.com/brainglobe/BrainGlobe/issues/33 :scream:

As per the version 1 release plan, this repository should depend on the meta-package rather than the individual tooling packages themselves.

As such, have added brainglobe>=1.0.0 to the top of the dependency list. Have left in the explicit brainreg>=1.0.0 and cellfinder>=1.0.0 dependencies, even though these (or the most recent versions) should be fetched by the meta-package anyway. This just ensures that the minimum version of the meta-package that will be fetched must be one that adheres to our BrainGlobe version 1 update: IE fetching the new cellfinder package and brainreg plugins.

Depends on:

CI will fail until all of the above are met.

adamltyson commented 5 months ago

Have left in the explicit brainreg>=1.0.0 and cellfinder>=1.0.0 dependencies, even though these (or the most recent versions) should be fetched by the meta-package anyway.

Shall we remove these? it seems weird to have some specific packages pinned and not others. We have to keep the metapackage dependencies up to date anyway, so we may as well fully rely on that.

willGraham01 commented 5 months ago

Shall we remove these? it seems weird to have some specific packages pinned and not others. We have to keep the metapackage dependencies up to date anyway, so we may as well fully rely on that.

Up to you and how much faith you have in the metapackage :sweat_smile: I ran this by @alessandrofelder briefly last week and we came to the same conclusion - let's just depend on the metapackage and be vigilant, as it's better to test from a user-style install than a developer one.

Although @sfmig might want to preserve the explicit dependencies in her ASV benchmark dependencies? Theoretically though the metapackage will handle that too...

alessandrofelder commented 5 months ago

Although @sfmig might want to preserve the explicit dependencies in her ASV benchmark dependencies?

Should the benchmarks at some point mainly run on the development versions of the tools, to warn developers about problems before we release?

willGraham01 commented 5 months ago

Should the benchmarks at some point mainly run on the development versions of the tools, to warn developers about problems before we release?

Ideally yeah, though there's no nice way to get pip (within the ASV environment) to install development versions of our packages as it heads over to standard PyPI channels. I have a couple of ideas for a hack though, depending on how adventurous we're feeling.

alessandrofelder commented 5 months ago

Ideally yeah,

Cool, let's make that a separate issue to this :)

codecov[bot] commented 5 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (b2ba47e) 81.43% compared to head (3b664b0) 81.43%. Report is 1 commits behind head on main.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #72 +/- ## ======================================= Coverage 81.43% 81.43% ======================================= Files 29 29 Lines 1573 1573 ======================================= Hits 1281 1281 Misses 292 292 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

adamltyson commented 5 months ago

Merging this so we can release.