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

ENH: Determine build contents from VCS file listing #40

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

effigies
Copy link
Contributor

@effigies effigies commented Apr 7, 2023

This is a proof-of-concept. setuptools_scm provides both the version and file listing to setuptools, so this seems like an appropriate place to improve on hatchling's filtering of files based on VCS configuration. This should mean that we get both git and mercurial filtering.

This proposes adding a detect-files boolean flag to [tool.hatch.build.hooks.vcs]. The way this is set up is to accept the file listing from setuptools_scm, run it through the exclusion filters already in place, place the results in artifacts to exempt from exclusion filters, and then set the exclusion filters to universal.

If you have interest in supporting this use-case, I'm happy to update tests (some guidance would be appreciated but I can probably figure it out). I also would change version-file from mandatory to optional.

xref pypa/hatch#304

@effigies effigies force-pushed the enh/vcs-files branch 2 times, most recently from bf26ff1 to 45a492f Compare April 7, 2023 02:42
@RonnyPfannschmidt
Copy link
Collaborator

Note that the file finders api is the absolute worst

The plan is to provide a better api later

@effigies
Copy link
Contributor Author

effigies commented Apr 9, 2023

Duly noted. Are there issues to track to keep tabs on that effort? And do you recommend against this approach in the meantime? The alternative seems to be a full reimplementation of gitignore/hgignore logic inside hatchling itself.

@RonnyPfannschmidt
Copy link
Collaborator

No notes yet, the rough plan is to coordinate something after the setuptools_scm 8.x / vcs_versioning transition is done

@effigies
Copy link
Contributor Author

@ofek Any thoughts on this? I'm happy to commit to adapting to changes in the setuptools_scm 8/vecs_versioning API, when the time comes.

In my tests, it has been helpful at making debugging builds simpler locally, where my repository is less likely to be a clean clone.

@RonnyPfannschmidt
Copy link
Collaborator

Absolutely

The rough plan i have in mind is to migrate away from file finders and altering the setuptools commands to include both file lists and scm files

This will include better low level apis

I'd appreciate giving me a little hell/help on the finer details

But also a fair time flow warning

Im on paternity leave, time allocation for open source ain't working at all like I imagined and there is a tunnel vision mistake in setuptools_scm i have to recover from to release the 8.x series

@effigies
Copy link
Contributor Author

Im on paternity leave, time allocation for open source ain't working at all like I imagined

No worries at all. I completely understand that. And sorry, I wasn't trying to bug you but see if Ofek is interested in this functionality in this particular hatch plugin.

@RonnyPfannschmidt
Copy link
Collaborator

Not feeling bugged, but it helps to be aware of surrounding constraints, if my situation was different, we could commit to a vastly different time line

effigies and others added 9 commits November 5, 2023 11:45
Fixes mypy error:

  tests/conftest.py:18:5: error: Incompatible redefinition (redefinition with
  type "Callable[[Any, Any, Any, VarArg(Any), KwArg(Any)], Any]", original type
  "_RmtreeType")  [misc]
          def rmtree(path, ignore_errors=False, onerror=None, *args, **kwds)...
          ^
  tests/conftest.py:18:5: note: "function" is missing following "_RmtreeType" protocol member:
  tests/conftest.py:18:5: note:     avoids_symlink_attacks
pyproject.toml Outdated Show resolved Hide resolved
@effigies
Copy link
Contributor Author

@RonnyPfannschmidt Is there a new file finder API to start playing with? Or discussions you want some input on? Will have time to look into this again in about 3 weeks.

@RonnyPfannschmidt
Copy link
Collaborator

No, I'm happy to start exploring this after the pytest sprint next week

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.

3 participants