Conversation
|
I'll let others review the other files. |
|
many thanks @kalvdans 🍻 |
pyproject.toml
Outdated
| dependencies = [ | ||
| "numpy", | ||
| "pip!=21.3", | ||
| "s3fs", |
There was a problem hiding this comment.
Is this a run dependency or is this similar to tests? If the later would a test extra be a better location for this dependency?
There was a problem hiding this comment.
hi @jjhelmus it's a run dep needed via #68 see https://github.com/jjhelmus/pyfive/pull/68/files#diff-fa602a8a75dc9dcc92261bac5f533c2a85e34fcceaff63b3a3a81d9acde2fc52 - I can remove it here, and re-add it once if/when #68 gets merged?
There was a problem hiding this comment.
s3fs is a surprising dependency. Does this have to be installed to use pyfive in the way the majority of users use it (without lazy-loading chunks?)
Also I don't usually see a pip version in the dependencies - is that needed too?
There was a problem hiding this comment.
nevermind me, I double-checked #68 and s3fs is indeed a simple test dep like all the others like h5netcdf etc, am gonna move it there right now 👍
kmuehlbauer
left a comment
There was a problem hiding this comment.
Thanks @valeriupredoi for tackling this. Just two comments from my side.
| - uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 | ||
| - uses: conda-incubator/setup-miniconda@v3 |
There was a problem hiding this comment.
We might be able to reduce the setup time using https://github.com/mamba-org/setup-micromamba. Works quite well over at h5netcdf and xarray. But I'm fine with the proposed, too.
There was a problem hiding this comment.
that's a good point! We're using setup-miniconda with mamba in a lot of our projects and I know the folks there at conda-incubator too, that's why I used it here too. I reckon we can change to micromamba in the future, if we hit any performance issues 👍
There was a problem hiding this comment.
Yes, sure, my main point is minimizing the CI time. Less time, less energy consumption.
There was a problem hiding this comment.
same with us, in stark opposition to the Techbro movement 😁 This one's lightning fast too, it'll be even faster once they update the base mamba version, for which I already opened an issue 👍
| - name: Install Pyfive Test Mode | ||
| run: | | ||
| pip install -e .[test] | ||
| - name: Lint with flake8 |
There was a problem hiding this comment.
Would it make sense to split out linting in a separate job? For the packages I maintain I find it useful to see test breakages even if the linting fails.
There was a problem hiding this comment.
that's entirely up to you, folks! We stop and fail the workflow if eg pre-commit fails, but I guess that depends how much emphasis one project puts on linting. Eg here we can put a fail-fast: false clause so the workflow still fails but it runs all the steps without halting at the first failed step?
There was a problem hiding this comment.
I just noticed that the strategy already has a fail-fast: false so this would mean workflow runs all the steps and marks the wkflow as failed if one step failed, so we good here I reckon 👍
There was a problem hiding this comment.
Great! I must have overlooked the fail-fast setting.
|
many thanks for the review @kmuehlbauer 🍺 |
.github/workflows/pytest.yml
Outdated
| fail-fast: false | ||
| matrix: | ||
| python-version: ["3.8", "3.9", "3.10", "3.11", "3.12", "3.13"] | ||
| python-version: ["3.10", "3.11", "3.12", "3.13"] |
There was a problem hiding this comment.
Is there a compelling reason to drop Python 3.9? Is is supported until the end of Oct 2025 (https://endoflife.date/python)
There was a problem hiding this comment.
indeed! But a lot of other packages are dropping it like a hot potato - I don't think it's feasible to support it anymore (even if Pyfive has a very small dependency table). Though it's not make or break to me, so I can re-add it, and open an issue to remind us to remove it in eight months 👍
pyproject.toml
Outdated
| ] | ||
| dependencies = [ | ||
| "numpy", | ||
| "pip!=21.3", |
There was a problem hiding this comment.
pip should not be included as a package dependency. It is a front end that can be used to install pyfive but it is not needed at runtime.
There was a problem hiding this comment.
I tend to agree with you on this one, but the problem is that it becomes murky which pip is used where and by what - we should avoid using pip default from PyPI when working with conda packages. If you are 100% that this package will only need numpy as a build dependency, then we can remove pip here, but if Pyfive will start adding a number of new build dependencies from conda-forge then we should most deffo use the conda-forge pip (and have it as a build/install dependency)
There was a problem hiding this comment.
I'm a huge fan of conda-forge, but pyfive is a pure-Python package and I'm hoping it won't need to be built (or have build dependencies)
There was a problem hiding this comment.
sure, but other of its (possible future) dependencies may eg netCDF4 - getting those off PyPI is a bit of a pain 😁
There was a problem hiding this comment.
With this listed as a dependency pip will be installed into the environment from PyPI by the pip installed by conda but only if the upgrade strategy is eager (not the default) or something else required a different version of pip. In the current run the conda installed version is retained. I can't see any case where this would be needed, the packages listed here are installed by pip itself (or another PEP 517 front end).
There was a problem hiding this comment.
sure, but other of its (possible future) dependencies may eg
netCDF4- getting those off PyPI is a bit of a pain 😁
I hope, pyfive will never depend on netCDF4 as this depends on netcdf-c which depends on hdf5 which counters the efforts of pyfive, IMHO.
There was a problem hiding this comment.
ah no way, that was a somewhat anecdotal example 😃 Let me just remobe pip from the conda env, then - so that numpy is the only one left as install dep 👍
|
I don't think the For example the Test Python 3.10 run: |
This comment was marked as outdated.
This comment was marked as outdated.
|
Blast! I know what it is, I forgot to set the default run shell at the top of the workflow - without it it'll always ignore any active environment 😮💨 |
fixed in 8de5832 - that was a sneaky one, great eye for it! 🍺 |
Co-authored-by: Jonathan J. Helmus <jjhelmus@gmail.com>
|
also relevant to dropping support for Python 3.9 (and 3.10) is SPEC0 if you folks think about subscribing to it 👍 |
|
@jjhelmus what do you reckon, mate - this one's good for merging? 🍺 |
|
As mentioned in #51, I want to get other involved in this project. I cannot be the only one reviewing and merging PR. Ideally I wouldn't need to do either. If someone else can review and merge this PR it would be appreciated. |
|
sounds like a solid plan to me, cheers @jjhelmus 🍺 @kmuehlbauer @bmaranville @davidhassell any of you good folk has a minute to have a final review and merge - if all's in order, please? 🍻 |
pyproject.toml
Outdated
|
|
||
| [tool.coverage.run] | ||
| parallel = true | ||
| source = ["esmvalcore"] |
There was a problem hiding this comment.
esmvalcore does not fit here.
There was a problem hiding this comment.
my bad, inspiration for the file from another of our packages 😁 Fixed in 62a5b39
kmuehlbauer
left a comment
There was a problem hiding this comment.
I think this PR has been discussed extensively and suggestions have been incorporated.
I found one more item which needs change, but otherwise this is good to go.
|
very many thanks @kmuehlbauer - fixed that little wiggle :beer |
|
Thanks @valeriupredoi. |
|
wonderful, great many thanks @kmuehlbauer and everyone else 🍻 |
Hi @jjhelmus in addition to @bnlawrence's #68 I have put together a PR that is updating the
pyfivepackage to fairly modern standards, by:and a few other small bits and bobs. Please let me know what you think - and many thanks, and a good weekend 🍺