-
Notifications
You must be signed in to change notification settings - Fork 11
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
fix: determine package version even in deactivated venv #387
Conversation
97378b7
to
30641a0
Compare
30641a0
to
66d2e0d
Compare
@behnazh after our conversation today we could add after these two lines python-package-template/Makefile Lines 6 to 8 in 66d2e0d
the following ifeq ($(PACKAGE_VERSION),unknown)
$(warning Unable to determine package version, proceeding anyway)
endif That way, a user shouldn’t be surprised anymore if |
Shouldn't we exit with a failure when package version is |
Thing is that |
No, I think the code as it is captures the issues and we don't need more warnings. |
Thank you @behnazh for noticing the regression with v2.4.1, introduced by PR #346. The problem is (still and again 🤦🏻♂️) that we don’t set up a venv in a Github runner and therefore we shouldn’t rely on the
VIRTUAL_ENV
environment variable.This change expands the Python command so that the command always returns a package version string (which may be
"unknown"
) instead of failing theimport package
.I think it’s safe to expect
"unknown"
formake venv
(or its Action equivalent)python-package-template/.github/workflows/build.yaml
Lines 70 to 71 in 7bf474b
and
make setup
python-package-template/.github/workflows/build.yaml
Lines 72 to 73 in 7bf474b
because the package hasn’t been installed yet, and therefore its version can’t be determined.
However, after
make setup
the package’s version can be determined safely—with or without virtual environment. For example, the artifacts attached to workflow run 3488321082 indeed contain the correct package version number again: