Comments (11)
Umm, I don't know if I understand the problem.
Let's suppose that in the CI, we use setup-python
to install in the same CI job worker, Python versions: 3.8, 3.10 and 3.12. To ensure noxfile.py
works well, then we have to set the environment variable the environment variable NOXFILE_PYTHON_VERSIONS="3.8 3.10 3.12"
before running nox
. This way it should not matter (🤞) which Python we use to install nox
, for each different section nox
should take care of spawning the correct virtual environments and combining then consistently when reporting.
Now if contributors want to update the table.md
file, in their personal computer they will also need to install the same Python versions used in the CI and set the environment variable NOXFILE_PYTHON_VERSIONS="3.8 3.10 3.12"
before using the procedure described in the README.md
.
This is how I suppose it would work, but the best would be actually check that against the github CI. Maybe other unforeseen errors will appear...
If that is too complicated, we can also drop all togheter this idea of checking if table.md
is updated accordingly... Just pick the combinations of Python versions and nox
sessions that we know should work and only run those...
from sample-namespace-packages.
Sounds good! I'll take a look at that.
from sample-namespace-packages.
This might be useful in the context of running the whole nox matrix to generate the complete compatibility report:
https://github.com/actions/setup-python/releases/tag/v4.4.0
from sample-namespace-packages.
fail if there is any uncommitted alteration in that file specifically
One concern I have is that there might be different results across different Python versions (that's what this repository is intended to determine, right), for which the user can't possibly determine the compatibility, thus running the whole workflow with different Python versions on a pull request will most probably result in a CI failure?
from sample-namespace-packages.
Hi @chrysle, I believe the best is to run all the Python versions from a since CI job.
Probably https://github.com/actions/setup-python/releases/tag/v4.4.0 (see release notes) can be used for that.
Otherwise, it would be necessary to find out a way of integrating/merging the report from different jobs, before converting them to a table and deciding if whole CI workflow passes or not. Individually running nox
for a single Python version is not really useful.
This happens because the noxfile.py
was designed to run all the sessions (with the different Python versions) at once and only at the end of all sessions, generate a report file (which can then be processed by the script that creates the table).
I don't think this fits in the idea of mapping each Python version to a different CI job (running in a different container/VM).
from sample-namespace-packages.
I believe the best is to run all the Python versions from a since CI job
I agree with that. But if I've understood correctly, the different table reports for the Python versions will be combined into one compatibility matrix. And if running the nox
sessions results with, for example, 3.10, in a different table than with 3.8,
which the user employed to update the table, won't the CI process on a PR fail?
from sample-namespace-packages.
Thanks for your patience, I suppose I had a little short-circuit here. I'll look into implementing that soon.
from sample-namespace-packages.
Don't worry, me too to be honest. The way the noxfile.py
is written and how the report is generated is a bit cumbersome to translate to Github CI. I scratched my head many times already about this 😆.
from sample-namespace-packages.
@chrysle this is a quick test I did to see if a single job can run multiple nox sessions:
I used a .python-version
to maintain a single source of truth for both Github Actions and nox
. (.python-version
was just an arbitrary name that can be chosen differently).
(Although usually GHA can read from .python-version
automatically, it seems that you need to manually set that when you are attempting to use multiple python versions -- see actions/setup-python#734).
from sample-namespace-packages.
@chrysle this is a quick test I did to see if a single job can run multiple nox sessions:
Thank you @abravalheri, that is really useful!
I used a
.python-version
to maintain a single source of truth for both Github Actions andnox
. (.python-version
was just an arbitrary name that can be chosen differently).
Good idea! Actually, we might rename the file since it would interfere with customization by pyenv
users?
from sample-namespace-packages.
Yeap, there should be no problem with that.
from sample-namespace-packages.
Related Issues (14)
- It's good as a skeleton example, but... HOT 3
- failing tests HOT 2
- install namespace package HOT 1
- native namespace package is missing an example of a single module portion HOT 1
- QUESTION: Namespace Packages HOT 7
- package data
- pkg_resource test transparently using pkgutil ? HOT 2
- Example showing the use of pyproject.toml file HOT 6
- Issue w/ pkgutil and setuptools > 31.0.0 HOT 4
- using native (no pkg __init__) in py2 HOT 1
- pkgutil example breaks with pip uninstall HOT 2
- table.md in master incorrect for pkgutil; overall better compatibility with zip_safe=False. HOT 5
- Keeping version information in table.md. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sample-namespace-packages.