multiCMD 1.57__tar.gz → 1.58__tar.gz

{multicmd-1.57 → multicmd-1.58}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: multiCMD
-Version: 1.57
+Version: 1.58
 Summary: Run commands simultaneously
 Home-page: https://github.com/yufei-pan/multiCMD
 Author: Yufei Pan
@@ -56,7 +56,7 @@ It works both as a command-line tool and as an importable wrapper around
 pip install multiCMD
 ```
 
-This installs the module and three equivalent console entry points:
+This installs the module and three equivalent commands:
 
 ```bash
 mcmd
@@ -491,6 +491,15 @@ pytest -m "not slow"   # skip intentional sleep-heavy cases
 
 `test_expand_ranges_perf.py` is a manual performance microbenchmark and is not collected by pytest.
 
+## Upgrading to 1.58 from 1.57
+
+- The `multiCMD` command is now a script file, not an entry point, so `entry_points.txt` no longer has two names that differ only in case. All three commands still work the same way, except in the venv case below. From 1.58 on, stock pip 9 on EL7 and EL8 upgrades and uninstalls multiCMD without `configparser.DuplicateOptionError`.
+- With pip 9, the pip of EL7 and EL8 (`pip3 --version`), upgrading from 1.57 or earlier and `pip3 uninstall multiCMD` of those releases stop with `configparser.DuplicateOptionError: ... option 'multicmd' in section 'console_scripts' already exists`, and nothing changes: the installed release keeps working. Run `pip3 install -U pip` once, then upgrade or uninstall.
+- With `--user` the same happens, except that `pip3 install --user -U multiCMD` with no version does not stop: it installs the new release, which works, and leaves the old release's metadata behind. `pip3 list` then shows the old release after `pip3 uninstall multiCMD`, and the next uninstall stops with that error. To avoid this, run `pip3 install --user -U pip` once first. If it has already happened, run that, run `pip3 uninstall multiCMD` until it says multiCMD is not installed, and install again. From 1.58 on the same upgrade leaves the metadata too, but with no error: `pip3 uninstall multiCMD` takes one run per release left.
+- Without `--user`, with multiCMD 1.57 or earlier installed, `pip3 install -U hpcp`, `statblk` or `statbtrfs` stops the same way once a newer multiCMD is out, because pip 9 upgrades dependencies too. `pip3 install -U --no-deps hpcp` gets past it.
+- With pip 10 or later, in a venv whose path has a space or is too long for the kernel's `#!` line, the `multiCMD` spelling does not start (the error varies: "bad interpreter", `import: command not found`), because pip gives a script file a plain `#!` line: use `multicmd`. With pip 9 no spelling starts in such a venv, as in 1.57. uv and system or `--user` installs are not affected.
+- An embedded copy made by the generator now falls back from any failure to import the installed multiCMD, not only the three errors it named.
+
 ## Upgrading to 1.57 from 1.56
 
 - Faster command starts on Python 3.6 - 3.10: the wrapper that puts a command in its own process group

{multicmd-1.57 → multicmd-1.58}/README.md

@@ -30,7 +30,7 @@ It works both as a command-line tool and as an importable wrapper around
 pip install multiCMD
 ```
 
-This installs the module and three equivalent console entry points:
+This installs the module and three equivalent commands:
 
 ```bash
 mcmd
@@ -465,6 +465,15 @@ pytest -m "not slow"   # skip intentional sleep-heavy cases
 
 `test_expand_ranges_perf.py` is a manual performance microbenchmark and is not collected by pytest.
 
+## Upgrading to 1.58 from 1.57
+
+- The `multiCMD` command is now a script file, not an entry point, so `entry_points.txt` no longer has two names that differ only in case. All three commands still work the same way, except in the venv case below. From 1.58 on, stock pip 9 on EL7 and EL8 upgrades and uninstalls multiCMD without `configparser.DuplicateOptionError`.
+- With pip 9, the pip of EL7 and EL8 (`pip3 --version`), upgrading from 1.57 or earlier and `pip3 uninstall multiCMD` of those releases stop with `configparser.DuplicateOptionError: ... option 'multicmd' in section 'console_scripts' already exists`, and nothing changes: the installed release keeps working. Run `pip3 install -U pip` once, then upgrade or uninstall.
+- With `--user` the same happens, except that `pip3 install --user -U multiCMD` with no version does not stop: it installs the new release, which works, and leaves the old release's metadata behind. `pip3 list` then shows the old release after `pip3 uninstall multiCMD`, and the next uninstall stops with that error. To avoid this, run `pip3 install --user -U pip` once first. If it has already happened, run that, run `pip3 uninstall multiCMD` until it says multiCMD is not installed, and install again. From 1.58 on the same upgrade leaves the metadata too, but with no error: `pip3 uninstall multiCMD` takes one run per release left.
+- Without `--user`, with multiCMD 1.57 or earlier installed, `pip3 install -U hpcp`, `statblk` or `statbtrfs` stops the same way once a newer multiCMD is out, because pip 9 upgrades dependencies too. `pip3 install -U --no-deps hpcp` gets past it.
+- With pip 10 or later, in a venv whose path has a space or is too long for the kernel's `#!` line, the `multiCMD` spelling does not start (the error varies: "bad interpreter", `import: command not found`), because pip gives a script file a plain `#!` line: use `multicmd`. With pip 9 no spelling starts in such a venv, as in 1.57. uv and system or `--user` installs are not affected.
+- An embedded copy made by the generator now falls back from any failure to import the installed multiCMD, not only the three errors it named.
+
 ## Upgrading to 1.57 from 1.56
 
 - Faster command starts on Python 3.6 - 3.10: the wrapper that puts a command in its own process group

{multicmd-1.57 → multicmd-1.58}/multiCMD.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: multiCMD
-Version: 1.57
+Version: 1.58
 Summary: Run commands simultaneously
 Home-page: https://github.com/yufei-pan/multiCMD
 Author: Yufei Pan
@@ -56,7 +56,7 @@ It works both as a command-line tool and as an importable wrapper around
 pip install multiCMD
 ```
 
-This installs the module and three equivalent console entry points:
+This installs the module and three equivalent commands:
 
 ```bash
 mcmd
@@ -491,6 +491,15 @@ pytest -m "not slow"   # skip intentional sleep-heavy cases
 
 `test_expand_ranges_perf.py` is a manual performance microbenchmark and is not collected by pytest.
 
+## Upgrading to 1.58 from 1.57
+
+- The `multiCMD` command is now a script file, not an entry point, so `entry_points.txt` no longer has two names that differ only in case. All three commands still work the same way, except in the venv case below. From 1.58 on, stock pip 9 on EL7 and EL8 upgrades and uninstalls multiCMD without `configparser.DuplicateOptionError`.
+- With pip 9, the pip of EL7 and EL8 (`pip3 --version`), upgrading from 1.57 or earlier and `pip3 uninstall multiCMD` of those releases stop with `configparser.DuplicateOptionError: ... option 'multicmd' in section 'console_scripts' already exists`, and nothing changes: the installed release keeps working. Run `pip3 install -U pip` once, then upgrade or uninstall.
+- With `--user` the same happens, except that `pip3 install --user -U multiCMD` with no version does not stop: it installs the new release, which works, and leaves the old release's metadata behind. `pip3 list` then shows the old release after `pip3 uninstall multiCMD`, and the next uninstall stops with that error. To avoid this, run `pip3 install --user -U pip` once first. If it has already happened, run that, run `pip3 uninstall multiCMD` until it says multiCMD is not installed, and install again. From 1.58 on the same upgrade leaves the metadata too, but with no error: `pip3 uninstall multiCMD` takes one run per release left.
+- Without `--user`, with multiCMD 1.57 or earlier installed, `pip3 install -U hpcp`, `statblk` or `statbtrfs` stops the same way once a newer multiCMD is out, because pip 9 upgrades dependencies too. `pip3 install -U --no-deps hpcp` gets past it.
+- With pip 10 or later, in a venv whose path has a space or is too long for the kernel's `#!` line, the `multiCMD` spelling does not start (the error varies: "bad interpreter", `import: command not found`), because pip gives a script file a plain `#!` line: use `multicmd`. With pip 9 no spelling starts in such a venv, as in 1.57. uv and system or `--user` installs are not affected.
+- An embedded copy made by the generator now falls back from any failure to import the installed multiCMD, not only the three errors it named.
+
 ## Upgrading to 1.57 from 1.56
 
 - Faster command starts on Python 3.6 - 3.10: the wrapper that puts a command in its own process group

{multicmd-1.57 → multicmd-1.58}/multiCMD.egg-info/SOURCES.txt

@@ -7,6 +7,7 @@ multiCMD.egg-info/SOURCES.txt
 multiCMD.egg-info/dependency_links.txt
 multiCMD.egg-info/entry_points.txt
 multiCMD.egg-info/top_level.txt
+scripts/multiCMD
 tests/test_api.py
 tests/test_async_executor.py
 tests/test_cli.py
@@ -17,6 +18,7 @@ tests/test_env.py
 tests/test_expand_ranges.py
 tests/test_helpers.py
 tests/test_interrupts.py
+tests/test_packaging.py
 tests/test_parsing.py
 tests/test_ping.py
 tests/test_pool.py

{multicmd-1.57 → multicmd-1.58}/multiCMD.egg-info/entry_points.txt

@@ -1,4 +1,3 @@
 [console_scripts]
 mcmd = multiCMD:main
-multiCMD = multiCMD:main
 multicmd = multiCMD:main

{multicmd-1.57 → multicmd-1.58}/multiCMD.py

@@ -27,7 +27,7 @@ import traceback
 from pprint import pformat
 
 #%% global vars
-version = '1.57'
+version = '1.58'
 __version__ = version
 COMMIT_DATE = '2026-11-06'
 # fire-and-forget threads (run_commands with wait_for_return=False) that join_threads() waits on. multiCMD takes no

multicmd-1.58/scripts/multiCMD

@@ -0,0 +1,6 @@
+#!/usr/bin/env python3
+# The mixed-case command, installed as a script and not as an entry point (see setup.py).
+import sys
+from multiCMD import main
+if __name__ == '__main__':
+    sys.exit(main())

{multicmd-1.57 → multicmd-1.58}/setup.py

@@ -11,10 +11,12 @@ setup(
     author_email='pan@zopyr.us',
     url='https://github.com/yufei-pan/multiCMD',
     py_modules=['multiCMD'],
+    # The mixed-case command is a script file and not an entry point: pip 9 (stock on EL7 and EL8) reads entry_points.txt with a
+    # parser that folds case, so two commands that differ only in case make it fail to upgrade or uninstall the package.
+    scripts=['scripts/multiCMD'],
     entry_points={
         'console_scripts': [
             'mcmd=multiCMD:main',
-            'multiCMD=multiCMD:main',
             'multicmd=multiCMD:main',
         ],
     },

multicmd-1.58/tests/test_packaging.py

@@ -0,0 +1,26 @@
+"""The packaging: the commands setup.py installs."""
+import os
+import subprocess
+import sys
+from pathlib import Path
+
+import pytest
+
+PACKAGE_ROOT = Path(__file__).resolve().parents[1]
+
+
+def test_no_two_commands_differ_only_in_case(tmp_path):
+	pytest.importorskip("setuptools", reason="needs setuptools to run setup.py")
+	# pip 9 (stock on EL7 and EL8) reads entry_points.txt with a parser that folds case, so two commands that differ only
+	# in case make it fail to upgrade or uninstall the package. The mixed-case command is a script file (scripts=) instead.
+	result = subprocess.run([sys.executable, "setup.py", "-q", "egg_info", "--egg-base", str(tmp_path)],
+		cwd=str(PACKAGE_ROOT), env=dict(os.environ, PYTHONDONTWRITEBYTECODE="1"), stdout=subprocess.PIPE, stderr=subprocess.PIPE,
+		universal_newlines=True, timeout=120)
+	assert result.returncode == 0, result.stderr
+	egg_info = tmp_path / "multiCMD.egg-info"
+	entry_points = (egg_info / "entry_points.txt").read_text(encoding="utf-8")
+	names = [line.split("=")[0].strip() for line in entry_points.splitlines() if "=" in line]
+	assert sorted(names) == ["mcmd", "multicmd"]
+	# the mixed-case command ships in the sdist as a script, so the three spellings stay three commands
+	assert "scripts/multiCMD" in (egg_info / "SOURCES.txt").read_text(encoding="utf-8").splitlines()
+	assert (PACKAGE_ROOT / "scripts" / "multiCMD").read_text(encoding="utf-8").startswith("#!")