New release?🤔

[kloczek]

https://github.com/man-group/pytest-plugins/compare/v1.7.0...master shows 100 commits since last release.

Do you have any plans to elease new version soon? 🤔

[kamichal]

isn't this project dead?

[wpbonelli]

It would be nice to have some indication whether active maintenance is planned to resume, if giving potential external contributors write access is an option, or if forking is recommended. Thanks to the original developers.

[smarie]

Duplicate of #162

[jonbannister]

Hello! We have kicked off a project to resurrect this library. Hopefully we can start to make a dent in the issues in the next few weeks/months. I am trying to get a green build and then, hopefully, things will start moving quickly from there.

[smarie]

Great initiative @jonbannister !! This is maybe an opportunity to split the various plugins into several independent repos ? Maybe easier to maintain in the long run, as well as to migrate to standard CI/build repo templates. Some plugins are indeed more awaited by the community than others. (On my side it is really "pytest-profiling" that I make use of regularly)

[jonbannister]

The split is definitely something worth considering, though our priority is to get some long-requested fixes out for now. Which CI/build templates do you recommend? :)

[smarie]

I definitely recommend nox as build framework, and I believe that pyproject.toml is now mature enough to be used as the single place to put all lib and tools details.

The template that I use for all my open source work (see for example https://github.com/smarie/python-pytest-cases) is a bit outdated because I used a setup.cfg and not the pyproject.toml to configure all tools and package details, but if I had more time I would migrate that bit. I configured the github actions to execute all nox sessions in a generic way, so maybe the workflows can be of interest to you.

[kloczek]

nox is not needed. PEP517 based build is perfectly fine now (pip or using build).

[wwuck]

I’ve had success following parts of Hypermodern Python Cookiecutter but with replacing most of the linting tools with ruff. Ruff is incredibly fast compared to existing tools and includes a lot of features out of the box in one tool.

if you have any packages that aren’t pure-python then cibuildwheel would be useful.

Perhaps also take a look at https://packaging.python.org/en/latest/ and look at doing automatic publishing to PyPI from GitHub actions using trusted publishing.

[smarie]

nox is not needed. PEP517 based build is perfectly fine now (pip or using build).

Of course everyone has a different opinion and things evolve fast (i don't keep track that much) so you are probably correct. Yet, just to make sure I explain why people use nox: nox is not a build tool. nox is a reproducibility tool. it allows you to make sure that all developers AND CI/CD have the same build lifecycle with the same environment for each task. I am not aware yet that PEP517 can define ci/cd lifecycle and tasks, but if it does then yes, nox could be less useful.

Yes, I agree with you @wwuck , ruff is definitely better than flake8, we use it everywhere for internal projects (with more up to date templates than my open source projects :) )

[kloczek]

This is has nothing to do with anyone opinion. nox as well do not defines anything related to CI/CD which is just a procedure ..

[smarie]

It does not indeed, but can be used in that way :

(from https://github.com/smarie/python-makefun/actions/runs/9907427426)

The main benefit is that developers can run nox (instead of any kind of pre-commit hook, which is a viable alternative but that I personally dislike), to make sure that a PR is sane, before having it run on CI. Another viable alternative is to learn github workflow language and have your developers use a local github workflow runner to execute the flow before pushing. I do not like this option either, but it is also viable.

[jonbannister]

We have released 1.8.0! :) Please feel free to raise any further issues. Apologies again for the wait.

[kloczek]

Thank you 👍