I run Poetry in combination together with tox for my unittests.
[tox]
skipsdist = True
envlist = autofix,linters,unittests
isolated_build = True
[testenv:unittests]
commands =
poetry run pytest {posargs: {[pytest-config]posargs}}
I run the tests on my Jenkins Agent, which uses Python 3.9, but I also want to run my tests for Python 3.7 and 3.8.
Does anyone know how to do with Tox and Poetry?
I tried this:
envlist = autofix,linters,{py37,py38,py39}-unittests,pre-commit
but this results in:
C:\Users\xcg5847\Miniconda3\envs\testme\lib\site-packages\tox\config\__init__.py:670: UserWarning: conflicting basepython version (set 3.9, should be 3.7) for env 'py37-unittests';resolve conflict or set ignore_basepython
_conflict
There's a default section in tox, the [testenv] section. Note especially that this does not declare a name. This is the section that is run using the first available, or specifically selected, python executable.
Using the default section with envlist entry below should do the trick:
[tox]
skipsdist = True
envlist = py37,py38,autofix,linters
isolated_build = True
[testenv]
commands =
poetry run pytest {posargs: {[pytest-config]posargs}}
And then tox will use py37 and py38 to run the [testenv] section. Assuming you have autofix,linters defined somewhere below.
Bonus:
Use a envlist = py,autofix,linters configuration. The py will select the first python executable on your PATH. Handy for working with coworkers. And then, in your CI, you can run a dedicated python executable with tox -e py38. Food for thought.
Source
Related
I am using pyenv to select python 3.10.9:
pyenv global 3.10.9
python --version
Python 3.10.9
Poetry configuration file shows that Poetry should use the current python version:
(base) bob#Roberts-Mac-mini shims % poetry config --list (amended)
virtualenvs.create = true
virtualenvs.in-project = true
virtualenvs.prefer-active-python = true
but when I create a new poetry project:
poetry new --src newproject
in the generated pyproject.toml the python version is 3.11, which is the version that was active when I installed poetry itself (file amended):
(base) bob#Roberts-Mac-mini newproject % cat pyproject.toml
[tool.poetry]
name = "newproject"
version = "0.1.0"
description = ""
authors = ["XXXX YYYYYY <ZZZZZZZZZZ#gmail.com>"]
readme = "README.md"
packages = [{include = "newproject", from = "src"}]
[tool.poetry.dependencies]
python = "^3.11"
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
I see there's an experimental poetry setting: https://python-poetry.org/docs/configuration/#virtualenvsprefer-active-python-experimental
Are there hidden problems using it?
The other solution I can think of is editing the pyproject.toml file, change python to 3.10 and then use "poetry env use 3.10" to create the venv with 3.10. Is this ok?
Are there other solutions to force the new environment to 3.10.9?
What is the simplest way to make an alias for python -m myproject when the user installs the package myproject via pip?
Can poetry manages that?
Remainder: python -m myproject launches myproject/__main__.py.
It is possible. With Poetry, it is solved by its scripts feature in the pyproject.toml:
[tool.poetry.scripts]
my-command = "myproject.__main__:my_main"
where my_main is a function in myproject/__main__.py:
def my_main():
# ...
if __name__ == '__main__':
my_main()
From then on, you can poetry install again and then the my-command executable is available. Later, when one "pip-installs" your project, they also have the my-command executable available.
My entry points are setup like this
[options]
package_dir =
= package
packages = .
python_requires = >=3.6
[option.entry_points]
console_scripts =
cons = scripts.cons
gui_scripts =
gui = scripts.gui
I installed the package in editable mode with pip install -e .. I can import package through a Python REPL, but running cons or gui (these are not the real names) doesn't work. I found that the entry point scripts are indeed not placed in %LOCALAPPDATA%\Programs\Python\Python39\Scripts but %LOCALAPPDATA%\Programs\Python\Python39\Lib\site-packages\package.egg-link does exist
When using setuptools, this is because you installed the package in editable mode, and then tried to run it from the CLI. To use the command from the CLI, you may NOT install it in editable mode. Instead just use:
pip install .
Using flit allows for editable CLI installs.
I tried to install the Iron framework for Rust on Mac OS X 10.11.2, but it failed when I run cargo build or cargo run on compiling openssl's stuff:
failed to run custom build command for `openssl-sys-extras v0.7.4`
Process didn't exit successfully: `/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-apple-darwin")
debug=true opt-level=0
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CC_x86_64-apple-darwin = None
CC_x86_64_apple_darwin = None
HOST_CC = None
CC = None
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CFLAGS_x86_64-apple-darwin = None
CFLAGS_x86_64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-o" "/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/out/src/openssl_shim.o" "-c" "src/openssl_shim.c"
ExitStatus(Code(1))
command did not execute successfully, got: exit code: 1
--- stderr
src/openssl_shim.c:1:10: fatal error: 'openssl/hmac.h' file not found
#include <openssl/hmac.h>
^
1 error generated.
thread '<main>' panicked at 'explicit panic', /xxx/.cargo/registry/src/github.com-0a35038f75765ae4/gcc-0.3.21/src/lib.rs:772
openssl version seems OK:
$ openssl version
OpenSSL 0.9.8zg 14 July 2015
I don't know what I have to do in order to make this installation work and give Iron a try.
As of rust-openssl version 0.8, Homebrew-installed OpenSSL libraries will be automatically detected by the crate, there is no need to set extra environment variables.
If you need to support a version prior to that or choose to not use Homebrew, read on.
This is a known issue (also this and this), but not one that the crate can fix.
The quick solution is to install OpenSSL with Homebrew and then explicitly point to the directories where OpenSSL is found by setting the OPENSSL_INCLUDE_DIR and OPENSSL_LIB_DIR environment variables:
OPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl/1.0.2e/include \
OPENSSL_LIB_DIR=/usr/local/Cellar/openssl/1.0.2e/lib \
cargo build
If you've already done one cargo build, you will need to run cargo clean first to clear our some stale cached information.
If you don't want to set this for every shell you open, add it to your shell initialization files (like ~/.bash_profile). You can make it a bit less brittle by not hard-coding the version number:
export OPENSSL_INCLUDE_DIR=$(brew --prefix openssl)/include
export OPENSSL_LIB_DIR=$(brew --prefix openssl)/lib
If you don't want to use Homebrew, follow the same process but using the appropriate path to your copy of OpenSSL.
The longer reason is well described by andrewtj:
OpenSSL doesn't have a stable ABI so for compatibility purposes Apple have maintained a fork that's compatible with one of the earlier ABIs. They deprecated OpenSSL in 10.7 and finally dropped the headers in 10.11 to push OS X app developers toward bundling their own OpenSSL or using their frameworks. The dylibs have been left around so apps that haven't been updated don't break. You can still link against them but you're opening yourself up to odd compatibility issues by doing so (unless you grab the headers from an earlier OS X release).
With Brew use like this:
brew install openssl
export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib
cargo clean
cargo build
If you have homebrew's openssl installed just add the following to your Cargo.toml:
[target.x86_64-apple-darwin.openssl-sys]
rustc-link-search = [ "/usr/local/opt/openssl/lib" ]
rustc-link-lib = [ "ssl", "crypto" ]
include = [ "/usr/local/opt/openssl/include" ]
and then cargo clean && cargo build. No breaking OS X by introducing an incompatible openssl into the library load paths, and no forgetting to set/unset environment variables when you want to build (or polluting your shell env when not working on Rust stuff). All in all a much happier and less infuriating approach.
I can't add this answer to my own question where it belongs (because it depends on homebrew), because Shepmaster decided it should be closed but I'll answer here and link to that question.
https://stackoverflow.com/a/39380733/1317564's answer for MacPorts:
sudo port install openssl
export OPENSSL_INCLUDE_DIR=/opt/local/include
export OPENSSL_LIB_DIR=/opt/local/lib
cargo clean
cargo build
I tried to install the Iron framework for Rust on Mac OS X 10.11.2, but it failed when I run cargo build or cargo run on compiling openssl's stuff:
failed to run custom build command for `openssl-sys-extras v0.7.4`
Process didn't exit successfully: `/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/build-script-build` (exit code: 101)
--- stdout
TARGET = Some("x86_64-apple-darwin")
OPT_LEVEL = Some("0")
PROFILE = Some("debug")
TARGET = Some("x86_64-apple-darwin")
debug=true opt-level=0
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CC_x86_64-apple-darwin = None
CC_x86_64_apple_darwin = None
HOST_CC = None
CC = None
HOST = Some("x86_64-apple-darwin")
TARGET = Some("x86_64-apple-darwin")
HOST = Some("x86_64-apple-darwin")
CFLAGS_x86_64-apple-darwin = None
CFLAGS_x86_64_apple_darwin = None
HOST_CFLAGS = None
CFLAGS = None
running: "cc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-o" "/xxx/rust/hello/target/debug/build/openssl-sys-extras-413d6c73b37a590d/out/src/openssl_shim.o" "-c" "src/openssl_shim.c"
ExitStatus(Code(1))
command did not execute successfully, got: exit code: 1
--- stderr
src/openssl_shim.c:1:10: fatal error: 'openssl/hmac.h' file not found
#include <openssl/hmac.h>
^
1 error generated.
thread '<main>' panicked at 'explicit panic', /xxx/.cargo/registry/src/github.com-0a35038f75765ae4/gcc-0.3.21/src/lib.rs:772
openssl version seems OK:
$ openssl version
OpenSSL 0.9.8zg 14 July 2015
I don't know what I have to do in order to make this installation work and give Iron a try.
As of rust-openssl version 0.8, Homebrew-installed OpenSSL libraries will be automatically detected by the crate, there is no need to set extra environment variables.
If you need to support a version prior to that or choose to not use Homebrew, read on.
This is a known issue (also this and this), but not one that the crate can fix.
The quick solution is to install OpenSSL with Homebrew and then explicitly point to the directories where OpenSSL is found by setting the OPENSSL_INCLUDE_DIR and OPENSSL_LIB_DIR environment variables:
OPENSSL_INCLUDE_DIR=/usr/local/Cellar/openssl/1.0.2e/include \
OPENSSL_LIB_DIR=/usr/local/Cellar/openssl/1.0.2e/lib \
cargo build
If you've already done one cargo build, you will need to run cargo clean first to clear our some stale cached information.
If you don't want to set this for every shell you open, add it to your shell initialization files (like ~/.bash_profile). You can make it a bit less brittle by not hard-coding the version number:
export OPENSSL_INCLUDE_DIR=$(brew --prefix openssl)/include
export OPENSSL_LIB_DIR=$(brew --prefix openssl)/lib
If you don't want to use Homebrew, follow the same process but using the appropriate path to your copy of OpenSSL.
The longer reason is well described by andrewtj:
OpenSSL doesn't have a stable ABI so for compatibility purposes Apple have maintained a fork that's compatible with one of the earlier ABIs. They deprecated OpenSSL in 10.7 and finally dropped the headers in 10.11 to push OS X app developers toward bundling their own OpenSSL or using their frameworks. The dylibs have been left around so apps that haven't been updated don't break. You can still link against them but you're opening yourself up to odd compatibility issues by doing so (unless you grab the headers from an earlier OS X release).
With Brew use like this:
brew install openssl
export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib
cargo clean
cargo build
If you have homebrew's openssl installed just add the following to your Cargo.toml:
[target.x86_64-apple-darwin.openssl-sys]
rustc-link-search = [ "/usr/local/opt/openssl/lib" ]
rustc-link-lib = [ "ssl", "crypto" ]
include = [ "/usr/local/opt/openssl/include" ]
and then cargo clean && cargo build. No breaking OS X by introducing an incompatible openssl into the library load paths, and no forgetting to set/unset environment variables when you want to build (or polluting your shell env when not working on Rust stuff). All in all a much happier and less infuriating approach.
I can't add this answer to my own question where it belongs (because it depends on homebrew), because Shepmaster decided it should be closed but I'll answer here and link to that question.
https://stackoverflow.com/a/39380733/1317564's answer for MacPorts:
sudo port install openssl
export OPENSSL_INCLUDE_DIR=/opt/local/include
export OPENSSL_LIB_DIR=/opt/local/lib
cargo clean
cargo build