Skip to content

version 0.2.4: move scipy/matplotlib/skimage into sub-func#41

Merged
yunjunz merged 1 commit intoinsarlab:mainfrom
yunjunz:main
Oct 24, 2022
Merged

version 0.2.4: move scipy/matplotlib/skimage into sub-func#41
yunjunz merged 1 commit intoinsarlab:mainfrom
yunjunz:main

Conversation

@yunjunz
Copy link
Copy Markdown
Member

@yunjunz yunjunz commented Oct 24, 2022

  • move scipy/matplotlib/skimage into the sub-functions, to avoid adding them to the requirements/host in the conda-forge recipe, as the latter is recommended by conda-forge guideline

  • add release Tag for version 0.2.4

+ move scipy/matplotlib/skimage into the sub-functions, to avoid adding them to the requirements/host in the conda-forge recipe, as the latter is recommended by conda-forge guideline

+ add release Tag for version 0.2.4
@yunjunz yunjunz merged commit cf2d017 into insarlab:main Oct 24, 2022
@jhkennedy
Copy link
Copy Markdown
Collaborator

@yunjunz where do you see this recommendation?

@yunjunz
Copy link
Copy Markdown
Member Author

yunjunz commented Oct 24, 2022

@yunjunz where do you see this recommendation?

Hi @jhkennedy, I was reading from here (https://conda-forge.org/docs/maintainer/adding_pkgs.html#build-host-and-run). My understanding from it is: scipy/matplotlib-base/scikit-image are supposed to be in requirements/run, which they are; but not recommended in the requirements/host, which was used during the building.

This is because of the change in setup.py in #40, where I use import pysolid.version to grab the version number. After that, the conda-forge feedstock testing failed due to the lack of the above 3 packages in conda-forge/pysolid-feedstock#10.

I am aware that moving them into the sub-function is not ideal, am happy to hear if you have more elegant solution.

@jhkennedy
Copy link
Copy Markdown
Collaborator

@yunjunz ah gotcha!

Generally, the recommendation is to not import your package in setup.py as your build and runtime requirements get mangled.

I agree it's desirable to provide the version number as a package variable and dynamically generate the version from the git history for dev versions, but you can do that without needing to import the package using tools like setuptools_scm. It would give you most of what you're doing in version.py for free. We're using it in the hyp3_sdk and a few other packages and have been really happy with it.

I could open a PR for that if you'd like.

@yunjunz
Copy link
Copy Markdown
Member Author

yunjunz commented Oct 24, 2022

That would be great @jhkennedy!

And you are also more than welcome to change setup.py to setup.cfg with pyproject.toml, if that makes your PR easier.

jhkennedy added a commit to jhkennedy/PySolid that referenced this pull request Oct 28, 2022
yunjunz added a commit that referenced this pull request Nov 3, 2022
+ add `pyproject.toml` to simplify `setup.py`

+ use `setuptools_scm` in `pyproject.toml` and `__init__.py` for the dynamic version number
   - remove the redundant `src/pysolid/version.py`
   - this allows the reversion of "move scipy/matplotlib/skimage into sub-func (#41)" (to move the module imports of matplotlib/scipy/skimage back to the top of the script)

+ add `.github/dependabot.yml` to keep actions up to date

+ README: fix typo + add explanation of editable install

+ update pypi workflow to use cibuildwheel for pip install:
   - rename publish-to-test-pypi.yml to build-and-publish-to-pypi.yml
   - use fortran build from cibuildwheel (see:pypa/cibuildwheel#404)
   - skip building wheel for windows as it's not working yet

+ deps: add the packaging/installation dependencies to requirements.txt and environment.yml:
   - pip
   - setuptools
   - setuptools_scm
   - wheel

Co-authored-by: Zhang Yunjun <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants