Adds version, fixes stop all bug, extra feedback when user select "n" for custom network #683

deadmanoz · 2025-02-18T03:42:41Z

Adds version:

warnet version
warnet version 1.1.11

Stop all bug - multiprocessing doesn't like local functions

warnet stop

Fixed:

warnet stop

Output from "n" on warnet new:

warnet new tester

Errant "\"

pinheadmz

concept ACK, see docs/developer-notes.md for instructions on passing lint test

pinheadmz · 2025-02-18T12:05:08Z

docs/warnet.md

+Check the version of warnet using `warnet version`.
+


2f365ee

The API docs are autogenerated by resources/scripts/apidocs.py which you can run locally to make sure the output looks correct. The CI will run this automatically on merged PRs so docs on main should always be up to date ;-)

Cool, thanks!

I had messed up my trunk setup so I was getting no linting being done locally

pinheadmz · 2025-02-18T21:03:12Z

Yeah, its annoying ...

--> ruff format .
2 files reformatted, 59 files left unchanged

--> git diff

diff --git a/src/warnet/main.py b/src/warnet/main.py
index 08d46809..b6250732 100644
--- a/src/warnet/main.py
+++ b/src/warnet/main.py
@@ -19,6 +19,7 @@ from .users import auth
 def cli():
     pass
 
+
 @click.command()
 def version() -> None:
     """Display the installed version of warnet"""
@@ -28,6 +29,7 @@ def version() -> None:
     except importlib.metadata.PackageNotFoundError:
         click.echo("warnet version unknown (package not installed)")
 
+
 cli.add_command(admin)
 cli.add_command(auth)
 cli.add_command(bitcoin)
diff --git a/src/warnet/project.py b/src/warnet/project.py
index cddbab6a..badc5aa8 100644
--- a/src/warnet/project.py
+++ b/src/warnet/project.py
@@ -432,7 +432,9 @@ def new_internal(directory: Path, from_init=False):
         click.secho("\nGenerating custom network...", fg="yellow", bold=True)
         custom_network_path = inquirer_create_network(directory)
     else:
-        click.echo(f"No custom network specified, see example network files in {project_path}/networks/")
+        click.echo(
+            f"No custom network specified, see example network files in {project_path}/networks/"
+        )
         click.echo("Deploy any of these networks by running:")
         click.echo(f"  warnet deploy {project_path}/networks/<example-network-name>")

deadmanoz · 2025-02-19T02:20:29Z

Oh man, thanks for your patience.

2 learnings:

Use the indicated tools and versions, and familiarise properly with any contributors guide
Make sure you're running the tools from the right directory

pinheadmz

ACK 2aab33c

Happy to merge this as-is, but wondering if we can squeeze in one more detail about version ...

Show Signature

pinheadmz's public key is on openpgp.org

pinheadmz · 2025-02-19T14:31:59Z

src/warnet/main.py

+    """Display the installed version of warnet"""
+    try:
+        version = importlib.metadata.version("warnet")
+        click.echo(f"warnet version {version}")


would it be possible to indicate if the code is modified from release, like
Bitcoin Core daemon version v28.99.0-78c19ddd7c56-dirty

Yeah I'll look into how this is done 💪

Ok there are a few options here so I'll need your guidance.

Using setuptools_scm seems to be the way to go for a Python-based project like this.

We have 2 ways to install Warnet, from source and from pypi.

If the user is installing from source, then the basic (default) setuptools_scm configuration I've added will yield versions like follows:
warnet version 1.1.11.dev8+dirty. I've confirmed this locally. This is using the "guess-next-dev" version-scheme.

If the user is installing from pypi then the reported version should report the tagged version: warnet version 1.1.11. I haven't been able to confirm this but this is basically what setuptools_scm is intended to do.

Now the "dirty" version suffix of the current configuration doesn't have the git commit details like Bitcoin Core, e.g. --short=12 HEAD, instead it has dev<number-of-commits-from-tag>:
warnet version 1.1.11.dev8+dirty
rather than
warnet version 1.1.11.e24df9e566fd-dirty

To instead use the git short commit in some way we would have to use a custom local version which can absolutely be done, my concern is that it might make things a bit more fragile without providing much additional utility.

Thoughts?

@pinheadmz I fixed the Ruff issues 🫠

deadmanoz · 2025-02-28T02:28:49Z

Ok @pinheadmz I have a potential solution that is now pushed to the branch/PR.

The situation is a bit more complex than originally anticipated as the following indicates, but we get the following outcome:

Warnet pulled from PyPI will report the current version, as it does now, but it no longer requires manually updating the pyproject.toml and instead uses the git tags via setuptools_scm from build time, e.g. 1.1.11. That is, references the _version.py that is created during build.
Warnet installed from source in editable mode will report a version that is based on the most recent git tag (as above), the most recent local git (short) commit, and whether there are uncommited local changes, e.g. 1.1.11.63fe5aa1-dirty. As in, won't reference the _version.py file, instead reports on the current repo/working directory state.

"one thing i notice about this is that since the _version file is written during setup, if youre editing the code and adding new commits it doesnt show up until you pip install -e . again"
"which IMO kinda defeats the purpose of this"

The complexity in implementation is related to the package build sequence, and what is possible with setuptools_scm & pyproject.toml: https://setuptools-scm.readthedocs.io/en/latest/customizing/

pyproject.toml is effectively a static configuration file that doesn't allow "arbitrary" code during installation which is great for security but not for customisation. You can only use the versioning format on offer (e.g. 1.1.11.dev6-dirty) and this won't change as local changes are made.

We need a setup.py where we implement the function for custom version - the above docs say "setuptools-scm has to piggyback on setuptools for passing functions over" when using custom functions.

So we have a hybrid approach:

Use pyproject.toml for static configuration
Use setup.py specifically for the custom version function

pinheadmz

ok sorry this had gotten bike shedded 😬

here's what im thinking:

try to get git commit
always get scm_version
if we got a commit, append it to whatever we got from scm_version

so, installing from release:
warnet 1.0.11

installing from github but checking out the exact 1.0.11 tag:
warnet 1.0.11-296e0ba2

pinheadmz · 2025-03-04T16:05:59Z

.gitignore

@@ -1,4 +1,5 @@
 .vscode
+.DS_Store


this is fine, but FYI you can add this to your own ~/.gitignore and it'll apply to everything ;-)

A global .gitignore, who woulda thought 😝

deadmanoz · 2025-03-06T15:01:31Z

Hey @pinheadmz it now does the below. No longer a need for setup.py.

I've been testing with test PyPI as you recommended (e.g. pip install -i https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ warnet-deadmanoz==100.0.0)

ok sorry this had gotten bike shedded 😬

here's what im thinking:

try to get git commit

always get scm_version

if we got a commit, append it to whatever we got from scm_version

so, installing from release: warnet 1.0.11

installing from github but checking out the exact 1.0.11 tag: warnet 1.0.11-296e0ba2

pinheadmz · 2025-03-07T16:00:33Z

Ok we're so close ;-)

Issue now is that the commit hash appended to the version string is from whatever repo you are currently working in.

For example cd to any git repo on your computer, create venv, install your test-pypi warnet and execute warnet version

(.venv) --> warnet version
warnet version 100.0.0-50426516
(.venv) --> git rev-parse HEAD
50426516511bfdac552d90026c80cde2ba359c43
(.venv) --> pwd
/Users/matthewzipkin/Desktop/work/battle-of-galen-erso

pinheadmz · 2025-03-07T16:01:08Z

at this point I am ok with just dropping all the commit hash stuff and just merging this so we at least have something.

deadmanoz · 2025-03-07T17:06:34Z

Ok we're so close ;-)

Issue now is that the commit hash appended to the version string is from whatever repo you are currently working in.

For example cd to any git repo on your computer, create venv, install your test-pypi warnet and execute warnet version
(.venv) --> warnet version
warnet version 100.0.0-50426516
(.venv) --> git rev-parse HEAD
50426516511bfdac552d90026c80cde2ba359c43
(.venv) --> pwd
/Users/matthewzipkin/Desktop/work/battle-of-galen-erso

Ahh frick, yeah we can't have that 😓

Ok. Finalised

deadmanoz · 2025-03-10T01:59:06Z

Ok take #12123721347

No subprocess & wrong git repo, no complexity with setuptools_scm setup.py.

Just use the metadata setuptools_scm provides, which includes node (the shortened commit id) and identification of "dirtyness", to generate version strings like:

1.1.11-932aaa5-dirty for source/editable installs: This is most recent tag plus the short commit hash, with dirty appended if the local working copy has uncommitted changes.
1.1.11 for PyPI releases. Just the semantic version from the git tag.

The main limitation is that it won't automatically update the commit hash when a user makes a local commit without reinstalling, because setuptools_scm only writes the version info to _version.py at install time.

P.S. We use local_scheme = "node-and-date" to get the node/shortened commit id information and version_scheme = "no-guess-dev" to ensure the patch component is not incremented (which is the default behaviour) and know when the working copy is dirty.

pinheadmz · 2025-03-10T13:53:35Z

GREAT thank, sorry for all the hassle. <3

deadmanoz added 4 commits February 18, 2025 11:17

Add version command

2f365ee

Fix "stop all" bug. Multiprocessing doesn't like local functions

0ff4d73

Fix incorrect GitHub URL

fa576ce

Extra output when user selects "n" for custom network on init/new

3982251

Errant "\"

pinheadmz reviewed Feb 18, 2025

View reviewed changes

Review feedback: linting and remove manual version documentation

f9c6f34

Ruff format

2aab33c

pinheadmz approved these changes Feb 19, 2025

View reviewed changes

deadmanoz added 6 commits February 26, 2025 09:32

Use setuptools_scm & tags for versioning

ccd9d98

Remove _version.py

e24df9e

post-release is deprecated

8915a8e

Ruff check & format

49fec67

Local and distribution versioning

217ac00

Merge branch 'testing-version' into add-version-fix-stop-all-bug

92dec09

deadmanoz mentioned this pull request Feb 28, 2025

Bug fixes, block generationg, and dependency updates a-mpch/replacement-cycling-attack#1

Merged

pinheadmz reviewed Mar 4, 2025

View reviewed changes

deadmanoz added 4 commits March 6, 2025 14:05

Remove .DS_Store from .gitignore (move to user global .gitignore)

a55ed48

Simplify versioning - don't append dirty, try get _version file first

d799f83

Ruff format

a51e047

base_version giving unwanted output, just use tag

54a1114

deadmanoz force-pushed the add-version-fix-stop-all-bug branch 2 times, most recently from 1fb68aa to a5bf800 Compare March 6, 2025 08:35

Remove setup.py, use setuptools_scm config

27af3a7

deadmanoz force-pushed the add-version-fix-stop-all-bug branch from a5bf800 to 27af3a7 Compare March 6, 2025 14:56

Don't use subprocess, just use version detected on install

0193078

Ok. Finalised

pinheadmz merged commit 240dc21 into bitcoin-dev-project:main Mar 10, 2025
15 checks passed

deadmanoz deleted the add-version-fix-stop-all-bug branch March 10, 2025 13:59

Adds version, fixes stop all bug, extra feedback when user select "n" for custom network #683

Adds version, fixes stop all bug, extra feedback when user select "n" for custom network #683

Uh oh!

Conversation

deadmanoz commented Feb 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pinheadmz left a comment

Choose a reason for hiding this comment

Uh oh!

pinheadmz Feb 18, 2025

Choose a reason for hiding this comment

Uh oh!

deadmanoz Feb 18, 2025

Choose a reason for hiding this comment

Uh oh!

pinheadmz commented Feb 18, 2025

Uh oh!

deadmanoz commented Feb 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pinheadmz left a comment

Choose a reason for hiding this comment

Uh oh!

pinheadmz Feb 19, 2025

Choose a reason for hiding this comment

Uh oh!

deadmanoz Feb 20, 2025

Choose a reason for hiding this comment

Uh oh!

deadmanoz Feb 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deadmanoz Feb 26, 2025

Choose a reason for hiding this comment

Uh oh!

deadmanoz commented Feb 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pinheadmz left a comment

Choose a reason for hiding this comment

Uh oh!

pinheadmz Mar 4, 2025

Choose a reason for hiding this comment

Uh oh!

deadmanoz Mar 5, 2025

Choose a reason for hiding this comment

Uh oh!

deadmanoz commented Mar 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pinheadmz commented Mar 7, 2025

Uh oh!

pinheadmz commented Mar 7, 2025

Uh oh!

deadmanoz commented Mar 7, 2025

Uh oh!

deadmanoz commented Mar 10, 2025

Uh oh!

pinheadmz commented Mar 10, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

deadmanoz commented Feb 18, 2025 •

edited

Loading

deadmanoz commented Feb 19, 2025 •

edited

Loading

deadmanoz Feb 26, 2025 •

edited

Loading

deadmanoz commented Feb 28, 2025 •

edited

Loading

deadmanoz commented Mar 6, 2025 •

edited

Loading