| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* deprecate more attributes in acme
* Deprecate .Authorization.combinations by renaming the field and
deprecating in getters/setters
* Silence deprecation warnings from our own imports of acme.mixins
Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
|
|
* deprecate source_address
* filter warnings
* fix route53 tests
* test warning
* update docstring
|
|
* Remove deprecation warnings
* update ci
* update setup.py files
* update changelog
* update pinnings
* update requests and friends
* update setuptools pin
* update setuptools pin pt2
* update pytz
* upgrade pyparsing
* upgrade boto deps
* update deps and docs
* update pyproject.toml comment
* remove trailets pin
* remove explicit PYTHON_VERSION
|
|
Fixes https://github.com/certbot/certbot/issues/8983
Python 3.6 is now EOL: https://endoflife.date/python
This is normally a good time to create warnings about Python 3.6 deprecation the Certbot upcoming release 1.23.0 so that its support is removed in 1.24.0.
We have to say here that EPEL maintainers asked us to keep maintaining support of Python 3.6 because Python 3.7 will never be shipped to CentOS 7. This support would be needed in theory up to 2 more years, basically until CentOS 7 EOL in 2024-06-30. It has been said that we could support as a best effort until a reasonable need on Certbot side requires to drop Python 3.6. See https://github.com/certbot/certbot/issues/8983 for more information.
However some of us (including me) consider that there is already a reasonable need right now. Indeed, keeping the support on Python 3.6 while the Python community globally moves away from it will pin implicitly some Certbot dependencies to the last version of these dependencies supporting Python 3.6 as the upstream maintainers decide to make the move. At any point in a future time, one of these dependencies could require an urgent upgrade (typically a critical uncovered vulnerability): then we would require to drop Python 3.6 immediately without further notice instead of following an organized deprecation path.
This reason motivates to proactively deprecate then drop the Python versions once they are EOL. You can see the discussion in Mattermost starting from [this post](https://opensource.eff.org/eff-open-source/pl/ntzs9zy1fprjmkso3xrqspnoce) to get more elements about the reasoning.
* Deprecate Python 3.6 support.
* Ignore our own PendingDeprecationWarning
|
|
Fixes https://github.com/certbot/certbot/issues/9058.
The changes to the CI config are equivalent to the ones made in https://github.com/certbot/certbot/pull/8460.
Other than ignoring some warnings raised by botocore, the main additional work that had to be done here was switching away from using `distutils.version.LooseVersion` since the entire `distutils` module was deprecated in Python 3.10. To do that, I took a few different approaches:
* If the version strings being parsed are from Python packages such as Certbot or setuptools, I switched to using [pkg_resources.parse_version](https://setuptools.pypa.io/en/latest/pkg_resources.html#parsing-utilities) from `setuptools`. This functionality has been available since [setuptools 8.0 from 2014](https://setuptools.pypa.io/en/latest/history.html#id865).
* If the version strings being parsed are not from Python packages, I added code equivalent to `distutils.version.LooseVersion` in `certbot.util.parse_loose_version`.
* The code for `CERTBOT_PIP_NO_BINARY` can be completely removed since that variable isn't used or referenced anywhere in this repo.
* add python 3.10 support
* make some version changes
* don't use looseversion in setup.py
* switch to pkg_resources
* deprecate get_strict_version
* fix route53 tests
* remove unused CERTBOT_PIP_NO_BINARY code
* stop using distutils in letstest
* add unit tests
* more changelog entries
|
|
* dns-rfc2136: use certbot's own is_ipaddress func
* oldest: pin dnspython==1.15.0 (epel8 version)
* inhibit deprecationwarning for dnspython==1.15.0
* dns-rfc2136: declare minimum version of dnspython
* add changelog entry
|
|
Fix #8982.
This PR takes essentially the same approach than in #8970 and https://github.com/certbot/certbot/pull/6859/files#diff-e5eaf744409c293203b898ba9896da75689fd04ff5f1566c035940a5b195c257
Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
|
|
* Monkeypatch certbot.interfaces module to warn about deprecations
* Ignore our own warning
* Fix type
* Add a changelog entry
|
|
* add oldest pyproject.toml file that works
* make single oldest_constraints.txt file
* remove unused merge_requirements.py
* remove unused import
* make conditional right
* simplify pip_install.py
* fix typo
* bump min dns-lexicon dependency
* fix zope import warning
* pin back wheel
* refactor pinning script
* Add oldest script.
* add pip comment
* add pipstrap extra
* simplify pinning scripts
* remove pipstrap extra
* update contributing
* Add design doc
* Update tools/pinning/DESIGN.md
Co-authored-by: ohemorange <erica@eff.org>
* Update tools/pinning/DESIGN.md
Co-authored-by: ohemorange <erica@eff.org>
* Update tools/pinning/DESIGN.md
Co-authored-by: ohemorange <erica@eff.org>
* Update tools/pinning/DESIGN.md
Co-authored-by: ohemorange <erica@eff.org>
* rename normal to current
* no dummies
* script improvements
* mention need to update setup.py
* try and clarify poetry behavior
* tweak section title
Co-authored-by: ohemorange <erica@eff.org>
|
|
* unpin pytest and update pinnings
* ignore external mock warnings
* fix assertion
* fix test_revoke_mutual_exclusive_flags
* fix output count
* capture stdout and stderr separately
* undouble counts
* rename variable
* don't use capture_output
* fix leaky test
* update coverage
|
|
|
|
Fixes #8389 #8584.
This PR makes the necessary modifications to officially drop Python 2 support in the Certbot project.
I did not remove the specific Python 2 compatibility branches that has been added in various places in the codebase, to reduce the size of this PR and this will be done in a future one
* Update classifiers and python_requires in setup.py
* Remove warnings about Python 2 deprecation
* Remove Azure jobs on Python 2.7
* Remove references to python 2 in documentation
* Pin dnspython to 2.1.0
* Update changelog
* Remove warning ignore
|
|
Fixes #8388
* Deprecate support for Python 2
* Ignore deprecation warning
* Update certbot/CHANGELOG.md
Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
|
|
Coming out of the conversation at #7863 in the linked Google Doc, we should always have at least 1 release between updating one of our plugins to stop using a deprecated acme/certbot API and removing it from acme/certbot. Doing this gives the plugin changes time to propagate rather than potentially having the plugin break because Certbot was updated before the plugin had made the necessary changes.
This comment here should help ensure this.
* Add pytest warnings warning.
* clarify comment
|
|
* Fix collections.abc imports for Python 3.9
* Update AUTHORS.md
* No longer ignore collections.abc deprecation warning
* Update changelog
* Remove outdated comment
* Disabling no-name-in-module not needed as linting is on Python 3
|
|
|
|
|
|
* fixes #7214
* update changelog
* remove unused import
|
|
Closes #7454
* Deprecate config_changes
* Error on config_changes
* Fix tests for main.py
* Fix CHANGELOG entry
* Remove remnants of config_changes
* Fix CHANGELOG and add removed functions
|
|
This pull request ensures that we use distro package in all the distribution version detection. It also replaces the custom systemd /etc/os-release parsing and adds a few version fingerprints to Apache override selection.
Fixes: #7405
* Revert "Try to use platform.linux_distribution() before distro equivalent (#7403)"
This reverts commit ca3077d0347aae12163a43bf74a0c8321284367e.
* Use distro for all os detection code
* Address review comments
* Add changelog entry
* Added tests
* Fix tests to return a consistent os name
* Do not crash on non-linux systems
* Minor fixes to distro compatibility checks
* Make the tests OS independent
* Update certbot/util.py
Co-Authored-By: Brad Warren <bmw@users.noreply.github.com>
* Skip linux specific tests on other platforms
* Test fixes
* Better test state handling
* Lower the coverage target for Windows tests
|
|
* Remove apache and nginx from config_changes help
* Deprecate certbot_config changes.
* Document config_changes deprecation.
* Remove view_config_changes as IInstaller method.
* Remove view_config_changes from plugins.
* Add view_config_changes warnings.
* simplify test_config_changes_deprecation
|
|
This PR is a part of the tls-sni-01 removal plan described in #6849.
As `acme` is a library, we need to put some efforts to make a decent deprecation path before totally removing tls-sni in it. While initialization of `acme.challenges.TLSSNI01` was already creating deprecation warning, not all cases were covered.
For instance, and innocent call like this ...
```python
if not isinstance(challenge, acme.challenges.TLSSNI01):
print('I am not using this TLS-SNI deprecated stuff, what could possibly go wrong?')
```
... would break if we suddenly remove all objects related to this challenge.
So, I use the _Deprecator Warning Machine, Let's Pacify this Technical Debt_ (Guido ®), to make `acme.challenges` and `acme.standalone` patch themselves, and display a deprecation warning on stderr for any access to the tls-sni challenge objects.
No dev should be able to avoid the deprecation warning. I set the deprecation warning in the idea to remove the code on `0.34.0`, but the exact deprecation window is open to discussion of course.
* Modules challenges and standalone patch themselves to generated deprecation warning when tls-sni related objects are accessed.
* Correct unit tests
* Correct lint
* Update challenges_test.py
* Correct lint
* Fix an error during tests
* Update coverage
* Use multiprocessing for coverage
* Add coverage
* Update test_util.py
* Factor the logic about global deprecation warning when accessing TLS-SNI-01 attributes
* Fix coverage
* Add comment for cryptography example.
* Use warnings.
* Add a changelog
* Fix deprecation during tests
* Reload
* Update acme/acme/__init__.py
Co-Authored-By: adferrand <adferrand@users.noreply.github.com>
* Update CHANGELOG.md
* Pick a random free port.
|
|
This PR in combination with #6713 resolves issues with using ipdb with pytest.
|
|
* Remove --numprocesses from pytest.ini.
* Add --numprocesses to PYTEST_ADDOPTS in tox.ini.
* complexity--
|
|
This PR passes the CERTBOT_NO_PIN environment variable to the unit tests tox envs. By setting CERTBOT_NO_PIN to 1 before executing a given tox env, certbot dependencies will be installed at their latest version instead of the usual pinned version.
I also moved the unpin logic one layer below to allow it to be used potentially more widely, and avoid unnecessary merging constraints operation in this case.
As warnings are errors now, latest versions of Python will break now the tests, because collections launch a warning when some classes are imported from collections instead of collections.abc. Certbot code is patched, and warning is ignored for now, because a lot of third party libraries still depend on this behavior.
* Allow to execute a tox target without pinned dependencies
* Correct lint
* Retrigger build.
* Remove debug code
* Added test against unpinned dependencies from test-everything-unpinned-dependencies branch
* Remove duplicated assertion to pass TRAVIS and APPVEYOR in default tox environment.
|
|
Currently the release script in master fails for a few reasons. First, it's trying to use --numprocesses which comes from a pytest plugin that we're not installing in the release script. Second, many new warnings are raised when we're not using pinned versions of our dependencies.
I'm not sure I agree, but one could argue that we should fix these issues and use the file during the release. I'm particularly hesitant for us to do this when it comes to warnings. We currently do not pin our dependencies in the release script. Do we really want to stop the release because a new package was released and is warning about something? One could argue we do because these warnings may be visible to the user, but they very rarely are and I think this makes the release process much too painful.
I especially do not think we should block the release on this now as we are not up to date on the warnings raised by the latest versions of our packages so there is a lot to work through.
* Don't use pytest.ini during the release.
* State that pytest.ini isn't used in release script.
|
|
|
|
|
|
should be catching all of them, and they usually fail to successfully error anyway, so this just means we get sligthly worse error messages when they do occur.
|
|
|
|
|
|
|
|
|
|
|
|
* Revert "Fix pytest on macOS in Travis (#5360)"
This reverts commit 5388842e5b3868e29caf545fb771a23e7fce4143.
* remove oldest passenv
|
|
* Add tools/pytest.sh
* pass TRAVIS through in tox.ini
* Use tools/pytest.sh to run pytest
* Add quiet to pytest.ini
* ignore pytest cache
|
