search

hasgeek / hasjob

Hasjob, the Hasgeek job board
https://hasjob.co
GNU Affero General Public License v3.0
237 stars 80 forks source link

Scheduled monthly dependency update for January #692

Closed pyup-bot closed 1 year ago

pyup-bot commented 1 year ago

Update coverage from 6.5.0 to 7.0.1.

Changelog ### 7.0.1 ``` -------------------------- - When checking if a file mapping resolved to a file that exists, we weren't considering files in .whl files. This is now fixed, closing `issue 1511`_. - File pattern rules were too strict, forbidding plus signs and curly braces in directory and file names. This is now fixed, closing `issue 1513`_. - Unusual Unicode or control characters in source files could prevent reporting. This is now fixed, closing `issue 1512`_. - The PyPy wheel now installs on PyPy 3.7, 3.8, and 3.9, closing `issue 1510`_. .. _issue 1510: https://github.com/nedbat/coveragepy/issues/1510 .. _issue 1511: https://github.com/nedbat/coveragepy/issues/1511 .. _issue 1512: https://github.com/nedbat/coveragepy/issues/1512 .. _issue 1513: https://github.com/nedbat/coveragepy/issues/1513 .. _changes_7-0-0: ``` ### 7.0.0 ``` -------------------------- Nothing new beyond 7.0.0b1. .. _changes_7-0-0b1: ``` ### 7.0.0b1 ``` <changes_7-0-0b1_>`_.) - Changes to file pattern matching, which might require updating your configuration: - Previously, ``*`` would incorrectly match directory separators, making precise matching difficult. This is now fixed, closing `issue 1407`_. - Now ``**`` matches any number of nested directories, including none. - Improvements to combining data files when using the :ref:`config_run_relative_files` setting: - During ``coverage combine``, relative file paths are implicitly combined without needing a ``[paths]`` configuration setting. This also fixed `issue 991`_. - A ``[paths]`` setting like ``*/foo`` will now match ``foo/bar.py`` so that relative file paths can be combined more easily. - The setting is properly interpreted in more places, fixing `issue 1280`_. - Fixed environment variable expansion in pyproject.toml files. It was overly broad, causing errors outside of coverage.py settings, as described in `issue 1481`_ and `issue 1345`_. This is now fixed, but in rare cases will require changing your pyproject.toml to quote non-string values that use environment substitution. - Fixed internal logic that prevented coverage.py from running on implementations other than CPython or PyPy (`issue 1474`_). .. _issue 991: https://github.com/nedbat/coveragepy/issues/991 .. _issue 1280: https://github.com/nedbat/coveragepy/issues/1280 .. _issue 1345: https://github.com/nedbat/coveragepy/issues/1345 .. _issue 1407: https://github.com/nedbat/coveragepy/issues/1407 .. _issue 1474: https://github.com/nedbat/coveragepy/issues/1474 .. _issue 1481: https://github.com/nedbat/coveragepy/issues/1481 .. _changes_6-5-0: ``` ### 6.6.0 ``` - Changes to file pattern matching, which might require updating your configuration: - Previously, ``*`` would incorrectly match directory separators, making precise matching difficult. This is now fixed, closing `issue 1407`_. - Now ``**`` matches any number of nested directories, including none. - Improvements to combining data files when using the :ref:`config_run_relative_files` setting, which might require updating your configuration: - During ``coverage combine``, relative file paths are implicitly combined without needing a ``[paths]`` configuration setting. This also fixed `issue 991`_. - A ``[paths]`` setting like ``*/foo`` will now match ``foo/bar.py`` so that relative file paths can be combined more easily. - The :ref:`config_run_relative_files` setting is properly interpreted in more places, fixing `issue 1280`_. - When remapping file paths with ``[paths]``, a path will be remapped only if the resulting path exists. The documentation has long said the prefix had to exist, but it was never enforced. This fixes `issue 608`_, improves `issue 649`_, and closes `issue 757`_. - Reporting operations now implicitly use the ``[paths]`` setting to remap file paths within a single data file. Combining multiple files still requires the ``coverage combine`` step, but this simplifies some single-file situations. Closes `issue 1212`_ and `issue 713`_. - The ``coverage report`` command now has a ``--format=`` option. The original style is now ``--format=text``, and is the default. - Using ``--format=markdown`` will write the table in Markdown format, thanks to `Steve Oswald <pull 1479_>`_, closing `issue 1418`_. - Using ``--format=total`` will write a single total number to the output. This can be useful for making badges or writing status updates. - Combining data files with ``coverage combine`` now hashes the data files to skip files that add no new information. This can reduce the time needed. Many details affect the speed-up, but for coverage.py's own test suite, combining is about 40% faster. Closes `issue 1483`_. - When searching for completely un-executed files, coverage.py uses the presence of ``__init__.py`` files to determine which directories have source that could have been imported. However, `implicit namespace packages`_ don't require ``__init__.py``. A new setting ``[report] include_namespace_packages`` tells coverage.py to consider these directories during reporting. Thanks to `Felix Horvat <pull 1387_>`_ for the contribution. Closes `issue 1383`_ and `issue 1024`_. - Fixed environment variable expansion in pyproject.toml files. It was overly broad, causing errors outside of coverage.py settings, as described in `issue 1481`_ and `issue 1345`_. This is now fixed, but in rare cases will require changing your pyproject.toml to quote non-string values that use environment substitution. - An empty file has a coverage total of 100%, but used to fail with ``--fail-under``. This has been fixed, closing `issue 1470`_. - The text report table no longer writes out two separator lines if there are no files listed in the table. One is plenty. - Fixed a mis-measurement of a strange use of wildcard alternatives in match/case statements, closing `issue 1421`_. - Fixed internal logic that prevented coverage.py from running on implementations other than CPython or PyPy (`issue 1474`_). - The deprecated ``[run] note`` setting has been completely removed. .. _implicit namespace packages: https://peps.python.org/pep-0420/ .. _issue 608: https://github.com/nedbat/coveragepy/issues/608 .. _issue 649: https://github.com/nedbat/coveragepy/issues/649 .. _issue 713: https://github.com/nedbat/coveragepy/issues/713 .. _issue 757: https://github.com/nedbat/coveragepy/issues/757 .. _issue 991: https://github.com/nedbat/coveragepy/issues/991 .. _issue 1024: https://github.com/nedbat/coveragepy/issues/1024 .. _issue 1212: https://github.com/nedbat/coveragepy/issues/1212 .. _issue 1280: https://github.com/nedbat/coveragepy/issues/1280 .. _issue 1345: https://github.com/nedbat/coveragepy/issues/1345 .. _issue 1383: https://github.com/nedbat/coveragepy/issues/1383 .. _issue 1407: https://github.com/nedbat/coveragepy/issues/1407 .. _issue 1418: https://github.com/nedbat/coveragepy/issues/1418 .. _issue 1421: https://github.com/nedbat/coveragepy/issues/1421 .. _issue 1470: https://github.com/nedbat/coveragepy/issues/1470 .. _issue 1474: https://github.com/nedbat/coveragepy/issues/1474 .. _issue 1481: https://github.com/nedbat/coveragepy/issues/1481 .. _issue 1483: https://github.com/nedbat/coveragepy/issues/1483 .. _pull 1387: https://github.com/nedbat/coveragepy/pull/1387 .. _pull 1479: https://github.com/nedbat/coveragepy/pull/1479 .. _changes_6-6-0b1: ``` ### 6.6.0b1 ``` ---------------------------- ```
Links - PyPI: https://pypi.org/project/coverage - Changelog: https://pyup.io/changelogs/coverage/ - Repo: https://github.com/nedbat/coveragepy

Update pytz from 2022.6 to 2022.7.

The bot wasn't able to find a changelog for this release. Got an idea?

Links - PyPI: https://pypi.org/project/pytz - Homepage: http://pythonhosted.org/pytz - Docs: https://pythonhosted.org/pytz/

Update SQLAlchemy from 1.4.44 to 1.4.45.

Changelog ### 1.4.45 ``` :released: December 10, 2022 .. change:: :tags: bug, orm :tickets: 8862 :versions: 2.0.0rc1 Fixed bug where :meth:`_orm.Session.merge` would fail to preserve the current loaded contents of relationship attributes that were indicated with the :paramref:`_orm.relationship.viewonly` parameter, thus defeating strategies that use :meth:`_orm.Session.merge` to pull fully loaded objects from caches and other similar techniques. In a related change, fixed issue where an object that contains a loaded relationship that was nonetheless configured as ``lazy='raise'`` on the mapping would fail when passed to :meth:`_orm.Session.merge`; checks for "raise" are now suspended within the merge process assuming the :paramref:`_orm.Session.merge.load` parameter remains at its default of ``True``. Overall, this is a behavioral adjustment to a change introduced in the 1.4 series as of :ticket:`4994`, which took "merge" out of the set of cascades applied by default to "viewonly" relationships. As "viewonly" relationships aren't persisted under any circumstances, allowing their contents to transfer during "merge" does not impact the persistence behavior of the target object. This allows :meth:`_orm.Session.merge` to correctly suit one of its use cases, that of adding objects to a :class:`.Session` that were loaded elsewhere, often for the purposes of restoring from a cache. .. change:: :tags: bug, orm :tickets: 8881 :versions: 2.0.0rc1 Fixed issues in :func:`_orm.with_expression` where expressions that were composed of columns that were referenced from the enclosing SELECT would not render correct SQL in some contexts, in the case where the expression had a label name that matched the attribute which used :func:`_orm.query_expression`, even when :func:`_orm.query_expression` had no default expression. For the moment, if the :func:`_orm.query_expression` does have a default expression, that label name is still used for that default, and an additional label with the same name will continue to be ignored. Overall, this case is pretty thorny so further adjustments might be warranted. .. change:: :tags: bug, sqlite :tickets: 8866 Backported a fix for SQLite reflection of unique constraints in attached schemas, released in 2.0 as a small part of :ticket:`4379`. Previously, unique constraints in attached schemas would be ignored by SQLite reflection. Pull request courtesy Michael Gorven. .. change:: :tags: bug, asyncio :tickets: 8952 :versions: 2.0.0rc1 Removed non-functional ``merge()`` method from :class:`_asyncio.AsyncResult`. This method has never worked and was included with :class:`_asyncio.AsyncResult` in error. .. change:: :tags: bug, oracle :tickets: 8708 :versions: 2.0.0b4 Continued fixes for Oracle fix :ticket:`8708` released in 1.4.43 where bound parameter names that start with underscores, which are disallowed by Oracle, were still not being properly escaped in all circumstances. .. change:: :tags: bug, postgresql :tickets: 8748 :versions: 2.0.0rc1 Made an adjustment to how the PostgreSQL dialect considers column types when it reflects columns from a table, to accommodate for alternative backends which may return NULL from the PG ``format_type()`` function. .. change:: :tags: usecase, sqlite :tickets: 8903 :versions: 2.0.0rc1 Added support for the SQLite backend to reflect the "DEFERRABLE" and "INITIALLY" keywords which may be present on a foreign key construct. Pull request courtesy Michael Gorven. .. change:: :tags: usecase, sql :tickets: 8800 :versions: 2.0.0rc1 An informative re-raise is now thrown in the case where any "literal bindparam" render operation fails, indicating the value itself and the datatype in use, to assist in debugging when literal params are being rendered in a statement. .. change:: :tags: usecase, sqlite :tickets: 8804 :versions: 2.0.0rc1 Added support for reflection of expression-oriented WHERE criteria included in indexes on the SQLite dialect, in a manner similar to that of the PostgreSQL dialect. Pull request courtesy Tobias Pfeiffer. .. change:: :tags: bug, sql :tickets: 8827 :versions: 2.0.0rc1 Fixed a series of issues regarding the position and sometimes the identity of rendered bound parameters, such as those used for SQLite, asyncpg, MySQL, Oracle and others. Some compiled forms would not maintain the order of parameters correctly, such as the PostgreSQL ``regexp_replace()`` function, the "nesting" feature of the :class:`.CTE` construct first introduced in :ticket:`4123`, and selectable tables formed by using the :meth:`.FunctionElement.column_valued` method with Oracle. .. change:: :tags: bug, oracle :tickets: 8945 :versions: 2.0.0rc1 Fixed issue in Oracle compiler where the syntax for :meth:`.FunctionElement.column_valued` was incorrect, rendering the name ``COLUMN_VALUE`` without qualifying the source table correctly. .. change:: :tags: bug, engine :tickets: 8963 :versions: 2.0.0rc1 Fixed issue where :meth:`_engine.Result.freeze` method would not work for textual SQL using either :func:`_sql.text` or :meth:`_engine.Connection.exec_driver_sql`. .. changelog:: ```
Links - PyPI: https://pypi.org/project/sqlalchemy - Changelog: https://pyup.io/changelogs/sqlalchemy/ - Homepage: https://www.sqlalchemy.org

Update SQLAlchemy-Utils from 0.38.3 to 0.39.0.

Changelog ### 0.39.0 ``` ^^^^^^^^^^^^^^^^^^^ - Support Python 3.11. - Add pre-commit hooks for uniform text checks, isort, flake8, and pyupgrade. - Fix a crash that occurs if the ``colour-science`` package is installed, which shares the same import name as the ``colour`` package that sqlalchemy-utils supports. (`637 <https://github.com/kvesteri/sqlalchemy-utils/pull/637>`_, courtesy of JayPalm) - Fix a crash that occurs if the installed sqlalchemy version is a beta (like ``"2.0.0b3"``). (Reported in `643 <https://github.com/kvesteri/sqlalchemy-utils/pull/643>`_, thanks Dinmukhamet!) ```
Links - PyPI: https://pypi.org/project/sqlalchemy-utils - Changelog: https://pyup.io/changelogs/sqlalchemy-utils/ - Repo: https://github.com/kvesteri/sqlalchemy-utils
CLAassistant commented 1 year ago

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.