Chore(deps): Bump aleph-pytezos from 0.1.1 to 3.13.4

[dependabot]

Bumps aleph-pytezos from 0.1.1 to 3.13.4.

Release notes

Sourced from aleph-pytezos's releases.

PyScaffold v4.0: interactive mode, inplace updates, saved configs, PEPS 420, 517, 518 and much more...

It has been a long journey since PyScaffold v3 was released and a lot of things happened in the Python community especially regarding the packaging ecosystem...

We saw emerging a huge effort to standardise the build process and metadata with PEP 517 and PEP 518, a tendency to avoid pkg_resources (in favour of native namespaces with PEP 420, importlib.resources and importlib.metadata) and of course the deprecation of Python version 2. Moreover, having Python 3.6 as the lowest version officially supported by Python's core team, changed the way developers write their code: a bunch of new features are now available, allowing us to be more expressive and succinct (don't tell me you don't like to use f-strings).

As a result, the PyScaffold team decided to expand our previous ideas for improvements and also incorporate these changes within the ecosystem into a new, super cool, version of PyScaffold. So here I am, proud to officially announce the final release of PyScaffold v4 - now available in PyPI 🥳🎉

The complete list of changes introduced in this version is available at the official website together with a more detailed description of all the features, but I will try to summarise below some highlights of this release.

New Defaults

As a response to PEP 517 and PEP 518, PyScaffold v4 will automatically generate a pyproject.toml in the root of your repository. As a consequence, most of the tools in Python's build ecosystem will assume the distribution should be built in isolation (think of it as creating a virtual environment just for running python setup.py). In general, this change should reduce the chances of things going wrong and improve reproducibility, but it can also mean that you need to adapt a little bit your workflow.

To ease this transition, we are including by default a tox.ini in the root of your project, pre-configured with a lot of common tasks. If you have tox installed in your machine, you will be able to run:

tox -e docs  # to build your documentation
tox -e build  # to build your package distribution
tox -e publish  # to test your project uploads correctly in test.pypi.org
tox -e publish -- --repository pypi  # to release your package to PyPI
tox -av  # to list all the tasks available

This is meant to be a replacement for deprecated setup.py commands such as:

python setup.py docs
python setup.py tests
# etc ...

We also are recommending using pip install . and pip install -e . instead of python setup.py install and python setup.py develop. In the future, it is very likely that running setup.py directly will be deprecated by setuptools, so we might as well start to get used to an interface that is unlikely to change.

Experimental and Exciting Features

Interactive Mode

Have you ever tried to use a CLI tool for the first time, or after a long period without using it, and faced a situation that forced you to go back and forth between typing your command and reading the --help text? It is usually not a great experience, especially when you have many options...

A few programs try to solve this problem by providing something called "interactive mode", which, most of the time, corresponds to a bunch of questions being prompted at the terminal. While this method is fine and familiar for most developers, it can get very tiring if the tool asks you more than 7 questions... and choosing by accident the wrong option in the last question, well, then you are going to hate having to reply to the same questions all over again...

Thus, we are trying something different in v4. When you activate the interactive mode with the -i or --interactive flags, PyScaffold will open your favourite text editor (the one you specify with the EDITOR environment variable), with an "editable version" of the --help text. A bit unusual right? But don't worry, it works very similarly to interactive rebases with git, i.e. you can comment options out by preceding the line with an # symbol, edit the values for the options (as shown in the example below), save and close the file then just wait for PyScaffold to run. This is how it looks:

  myproject
    # path where to generate/update project
</tr></table>

... (truncated)

Changelog

Sourced from aleph-pytezos's changelog.

========= Changelog

.. Development version ===================

Version 4.X.X, 2023-XX-XX
-------------------------

Development version

Version 4.6.0, 2024-09-23

• Modify Cirrus CI template to save resources, :pr:735
• Update Cirrus CI configuration, :pr:752
• Update Gitlab CI template, :pr:`756
• Prefer importlib.resources.files instead of importlib.resources.read_text or pkgutil.get_data, :pr:747
• Update version caps for dependency on platformdirs, :pr:755

Current versions

Version 4.5.0, 2023-06-20

• Change macOS default configuration dir from ~/Library/Preferences to ~/Library/Application Support, :pr:721. This change is motivated by the upgrade in the platformdirs dependency. You can read more about the motivation in :github:platformdirs/platformdirs#98
• Simplify git command, by letting exceptions go through, :pr:714

Version 4.4.1, 2023-04-18

• Reuse pre-built wheels in CI for upgrade tests in :pr:702
• Make security permissions explicit in GHA template :pr:704
• Fix GITHUB_TOKEN variable in GHA template :pr:715

Older versions

Version 4.4, 2023-01-23

... (truncated)

Commits

• See full diff in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[github-actions]

Failed to retrieve llama text: Invalid URL '/completion': No scheme supplied. Perhaps you meant https:///completion?

[Psycojoker]

See #148 to combine those 2 PRs

[foxpatch-aleph]

This is a single-line dependency pin bump of aleph-pytezos from 0.1.1 to 3.13.4 — a massive major-version jump. The code change itself is minimal and correct. However, the PR description's release notes and changelog link to pyscaffold/pyscaffold, not the actual aleph-pytezos package, which means there are no meaningful release notes to evaluate the impact of this bump. The jump from 0.1.1 to 3.13.4 likely reflects that aleph-pytezos versioning tracks upstream pytezos releases, but this should be confirmed before merging. The API surface used in tezos.py (Key.from_secret_exponent, Key.from_encoded_key, .sign(), .verify(), .public_key_hash(), .public_key()) appears unchanged, but without a verified changelog the API compatibility cannot be fully guaranteed.

pyproject.toml (line 83): The PR description's release notes and changelog point to pyscaffold/pyscaffold (not aleph-pytezos), so there is no reliable changelog available for this bump. Before merging, manually verify on PyPI or the aleph-im/aleph-pytezos GitHub that version 3.13.4 is the intended release and that the aleph_pytezos.crypto.key.Key API used in src/aleph/sdk/chains/tezos.py (specifically from_secret_exponent, from_encoded_key, sign, verify, public_key_hash, public_key) is unchanged. The version jump from 0.1.1 to 3.13.4 suggests the package version now tracks upstream pytezos, which would be a significant packaging change worth confirming.

[foxpatch-aleph]

This is a single-line dependency bump of aleph-pytezos from 0.1.1 to 3.13.4 — a very large version jump (0.x → 3.x). The package is used in src/aleph/sdk/chains/tezos.py via aleph_pytezos.crypto.key.Key with methods from_secret_exponent, from_encoded_key, sign, verify, public_key, and public_key_hash. The change itself is mechanically correct, but the magnitude of the version bump warrants explicit verification that the API surface used by tezos.py is unchanged. Notably, the PR description links to pyscaffold's changelog — dependabot appears to have confused the package URL — so the release notes shown are entirely irrelevant to aleph-pytezos. No bugs or security issues are apparent in the diff itself.

pyproject.toml (line 83): The jump from 0.1.1 to 3.13.4 is very large (major version change). The PR description's changelog and release notes are for pyscaffold, not aleph-pytezos — dependabot linked the wrong repository. Before merging, manually confirm that the aleph_pytezos.crypto.key.Key API used in tezos.py (specifically from_secret_exponent, from_encoded_key, sign, verify, public_key, public_key_hash) is compatible with 3.13.4. The Tezos unit tests in tests/unit/test_chain_tezos.py should be run against the new version to catch any breakage.

[foxpatch-aleph]

This is a large major version bump (0.1.1 → 3.13.4) of aleph-pytezos, which is likely the aleph.im fork of pytezos tracking upstream versioning. The single-line change in pyproject.toml is correct, and existing tests cover the relevant API surface (Key.from_secret_exponent, key.sign, key.public_key_hash, key.public_key, Key.from_encoded_key, key.verify). However, two things warrant attention before merging: the PR metadata links to pyscaffold/pyscaffold instead of aleph-pytezos, making it impossible to assess what changed in the package; and a major-version jump of this magnitude should be verified for API compatibility either via CI or manual inspection.

pyproject.toml (line 84): The dependabot PR description links to pyscaffold/pyscaffold for aleph-pytezos's release notes and changelog — the wrong repository entirely. This means the package's PyPI metadata has incorrect source links, and there is no actual changelog available in this PR to assess what changed between 0.1.1 and 3.13.4. Before merging, please manually verify the aleph-pytezos 3.13.4 package on PyPI (or its actual source repo) to confirm the API surface used in src/aleph/sdk/chains/tezos.py is unchanged: specifically Key.from_secret_exponent, Key.from_encoded_key, key.sign() return type (currently assumed to be a value on which .encode() is called), key.verify(), key.public_key(), and key.public_key_hash().

pyproject.toml (line 84): The version is pinned exactly (==3.13.4), which is consistent with the previous pin. This is acceptable for optional dependency groups but worth noting that any future patch releases of aleph-pytezos will require another PR like this one.