You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to propose a refactoring of the Makefile in order to improve the installation process and ensure compatibility with Python environments and package managers such as virtual environments and asdf.
Currently, the Makefile assumes the installation path based on the PYTHONVERSION variable, which may not be suitable when using package managers like asdf or when working within a virtual environment. To address this, I suggest using the SITE_PACKAGES_PATH variable, which provides a more reliable installation path across different environments.
Proposed change
Here is the proposed refactored code for the Makefile:
PYTHONVERSION=`python3 -c 'import sys; print("{}.{}".format(sys.version_info.major, sys.version_info.minor))'`
SITE_PACKAGES_PATH = `python -c "import site; print(site.getsitepackages()[0])"`
.PHONY: tests tests-python2
version:
@echo "$(PYTHONVERSION)"
doc:
echo "" > DOC
pydoc3 ./clap/* >> DOC
global-install:
make tests
make clean
mkdir $(SITE_PACKAGES_PATH)/clap
cp -v ./clap/*.py $(SITE_PACKAGES_PATH)/clap
install: ./clap/*.py
mkdir $(SITE_PACKAGES_PATH)/clap
cp -v ./clap/*.py $(SITE_PACKAGES_PATH)/clap
clean:
rm -rf ./clap/__pycache__
test:
python3 ./tests/clap/tests.py --catch --failfast --verbose
test-builder:
python3 ./tests/clap/buildertests.py --catch --failfast --verbose
test-example-ui-run:
python3 ./examples/nested.py > /dev/null
python3 ./examples/nested.py help > /dev/null
python3 ./examples/nested.py help help > /dev/null
python3 ./examples/nested.py help help --help > /dev/null
test-example-ui-helper-output:
@python3 ./examples/nested.py help
@python3 ./examples/nested.py help help
@python3 ./examples/nested.py help help --usage
test-cover: test test-builder test-example-ui-run
The main change is the introduction of the SITE_PACKAGES_PATH variable, which is set to the appropriate site packages directory using the site module in Python. This variable is then used in the install command.
This modification will enable users to install the clap package correctly, regardless of their Python environment or package manager by calling the make install command from an active virtualenv.
Let me know if you would like me to contribute this change and submit a pull request, or if you have any alternative thoughts. Thanks!
The text was updated successfully, but these errors were encountered:
- Update paths to use site.getsitepackages() for dynamic site-packages
location to improve installation flexibility.
- Add `uninstall` target to remove installed files and clean up
artifacts.
Fixesmarekjm#5
stelewis
added a commit
to stelewis/clap
that referenced
this issue
Oct 31, 2023
- Update paths to use site.getsitepackages() for dynamic site-packages
location to improve installation flexibility.
- Add `uninstall` target to remove installed files and clean up
artifacts.
Fixesmarekjm#5
Summary
I would like to propose a refactoring of the Makefile in order to improve the installation process and ensure compatibility with Python environments and package managers such as virtual environments and asdf.
Currently, the Makefile assumes the installation path based on the PYTHONVERSION variable, which may not be suitable when using package managers like asdf or when working within a virtual environment. To address this, I suggest using the SITE_PACKAGES_PATH variable, which provides a more reliable installation path across different environments.
Proposed change
Here is the proposed refactored code for the Makefile:
The main change is the introduction of the SITE_PACKAGES_PATH variable, which is set to the appropriate site packages directory using the site module in Python. This variable is then used in the install command.
This modification will enable users to install the clap package correctly, regardless of their Python environment or package manager by calling the
make install
command from an active virtualenv.Let me know if you would like me to contribute this change and submit a pull request, or if you have any alternative thoughts. Thanks!
The text was updated successfully, but these errors were encountered: