text:
Release v2023.7.23 not resolving all platform hashes when pulling from a custom index

Issue description
After upgrading to 2023.7.23 my Pipfile.lock is not populated with all platform hashes when a custom repo is configured.  Only the hashes for my OS platform are generated in Pipfile.lock.  When I disabled the custom repo, all platform hashes are generated.  I have not seen this behavior with earlier versions.
Expected result
I would expect all platform hashes to be generated in Pipfile.lock
{
    "_meta": {
        "hash": {
            "sha256": "90025a8184f3365cfb0e9f07920c49ce086e43ac5335361e1ca7a562e9ab9e30"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.10"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "cffi": {
            "hashes": [
                "sha256:00a9ed42e88df81ffae7a8ab6d9356b371399b91dbdf0c3cb1e84c03a13aceb5",
                "sha256:03425bdae262c76aad70202debd780501fabeaca237cdfddc008987c0e0f59ef",
                "sha256:04ed324bda3cda42b9b695d51bb7d54b680b9719cfab04227cdd1e04e5de3104",
                "sha256:0e2642fe3142e4cc4af0799748233ad6da94c62a8bec3a6648bf8ee68b1c7426",
                "sha256:173379135477dc8cac4bc58f45db08ab45d228b3363adb7af79436135d028405",
                "sha256:198caafb44239b60e252492445da556afafc7d1e3ab7a1fb3f0584ef6d742375",
                "sha256:1e74c6b51a9ed6589199c787bf5f9875612ca4a8a0785fb2d4a84429badaf22a",
                "sha256:2012c72d854c2d03e45d06ae57f40d78e5770d252f195b93f581acf3ba44496e",
                "sha256:21157295583fe8943475029ed5abdcf71eb3911894724e360acff1d61c1d54bc",
                "sha256:2470043b93ff09bf8fb1d46d1cb756ce6132c54826661a32d4e4d132e1977adf",
                "sha256:285d29981935eb726a4399badae8f0ffdff4f5050eaa6d0cfc3f64b857b77185",
                "sha256:30d78fbc8ebf9c92c9b7823ee18eb92f2e6ef79b45ac84db507f52fbe3ec4497",
                "sha256:320dab6e7cb2eacdf0e658569d2575c4dad258c0fcc794f46215e1e39f90f2c3",
                "sha256:33ab79603146aace82c2427da5ca6e58f2b3f2fb5da893ceac0c42218a40be35",
                "sha256:3548db281cd7d2561c9ad9984681c95f7b0e38881201e157833a2342c30d5e8c",
                "sha256:3799aecf2e17cf585d977b780ce79ff0dc9b78d799fc694221ce814c2c19db83",
                "sha256:39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21",
                "sha256:3b926aa83d1edb5aa5b427b4053dc420ec295a08e40911296b9eb1b6170f6cca",
                "sha256:3bcde07039e586f91b45c88f8583ea7cf7a0770df3a1649627bf598332cb6984",
                "sha256:3d08afd128ddaa624a48cf2b859afef385b720bb4b43df214f85616922e6a5ac",
                "sha256:3eb6971dcff08619f8d91607cfc726518b6fa2a9eba42856be181c6d0d9515fd",
                "sha256:40f4774f5a9d4f5e344f31a32b5096977b5d48560c5592e2f3d2c4374bd543ee",
                "sha256:4289fc34b2f5316fbb762d75362931e351941fa95fa18789191b33fc4cf9504a",
                "sha256:470c103ae716238bbe698d67ad020e1db9d9dba34fa5a899b5e21577e6d52ed2",
                "sha256:4f2c9f67e9821cad2e5f480bc8d83b8742896f1242dba247911072d4fa94c192",
                "sha256:50a74364d85fd319352182ef59c5c790484a336f6db772c1a9231f1c3ed0cbd7",
                "sha256:54a2db7b78338edd780e7ef7f9f6c442500fb0d41a5a4ea24fff1c929d5af585",
                "sha256:5635bd9cb9731e6d4a1132a498dd34f764034a8ce60cef4f5319c0541159392f",
                "sha256:59c0b02d0a6c384d453fece7566d1c7e6b7bae4fc5874ef2ef46d56776d61c9e",
                "sha256:5d598b938678ebf3c67377cdd45e09d431369c3b1a5b331058c338e201f12b27",
                "sha256:5df2768244d19ab7f60546d0c7c63ce1581f7af8b5de3eb3004b9b6fc8a9f84b",
                "sha256:5ef34d190326c3b1f822a5b7a45f6c4535e2f47ed06fec77d3d799c450b2651e",
                "sha256:6975a3fac6bc83c4a65c9f9fcab9e47019a11d3d2cf7f3c0d03431bf145a941e",
                "sha256:6c9a799e985904922a4d207a94eae35c78ebae90e128f0c4e521ce339396be9d",
                "sha256:70df4e3b545a17496c9b3f41f5115e69a4f2e77e94e1d2a8e1070bc0c38c8a3c",
                "sha256:7473e861101c9e72452f9bf8acb984947aa1661a7704553a9f6e4baa5ba64415",
                "sha256:8102eaf27e1e448db915d08afa8b41d6c7ca7a04b7d73af6514df10a3e74bd82",
                "sha256:87c450779d0914f2861b8526e035c5e6da0a3199d8f1add1a665e1cbc6fc6d02",
                "sha256:8b7ee99e510d7b66cdb6c593f21c043c248537a32e0bedf02e01e9553a172314",
                "sha256:91fc98adde3d7881af9b59ed0294046f3806221863722ba7d8d120c575314325",
                "sha256:94411f22c3985acaec6f83c6df553f2dbe17b698cc7f8ae751ff2237d96b9e3c",
                "sha256:98d85c6a2bef81588d9227dde12db8a7f47f639f4a17c9ae08e773aa9c697bf3",
                "sha256:9ad5db27f9cabae298d151c85cf2bad1d359a1b9c686a275df03385758e2f914",
                "sha256:a0b71b1b8fbf2b96e41c4d990244165e2c9be83d54962a9a1d118fd8657d2045",
                "sha256:a0f100c8912c114ff53e1202d0078b425bee3649ae34d7b070e9697f93c5d52d",
                "sha256:a591fe9e525846e4d154205572a029f653ada1a78b93697f3b5a8f1f2bc055b9",
                "sha256:a5c84c68147988265e60416b57fc83425a78058853509c1b0629c180094904a5",
                "sha256:a66d3508133af6e8548451b25058d5812812ec3798c886bf38ed24a98216fab2",
                "sha256:a8c4917bd7ad33e8eb21e9a5bbba979b49d9a97acb3a803092cbc1133e20343c",
                "sha256:b3bbeb01c2b273cca1e1e0c5df57f12dce9a4dd331b4fa1635b8bec26350bde3",
                "sha256:cba9d6b9a7d64d4bd46167096fc9d2f835e25d7e4c121fb2ddfc6528fb0413b2",
                "sha256:cc4d65aeeaa04136a12677d3dd0b1c0c94dc43abac5860ab33cceb42b801c1e8",
                "sha256:ce4bcc037df4fc5e3d184794f27bdaab018943698f4ca31630bc7f84a7b69c6d",
                "sha256:cec7d9412a9102bdc577382c3929b337320c4c4c4849f2c5cdd14d7368c5562d",
                "sha256:d400bfb9a37b1351253cb402671cea7e89bdecc294e8016a707f6d1d8ac934f9",
                "sha256:d61f4695e6c866a23a21acab0509af1cdfd2c013cf256bbf5b6b5e2695827162",
                "sha256:db0fbb9c62743ce59a9ff687eb5f4afbe77e5e8403d6697f7446e5f609976f76",
                "sha256:dd86c085fae2efd48ac91dd7ccffcfc0571387fe1193d33b6394db7ef31fe2a4",
                "sha256:e00b098126fd45523dd056d2efba6c5a63b71ffe9f2bbe1a4fe1716e1d0c331e",
                "sha256:e229a521186c75c8ad9490854fd8bbdd9a0c9aa3a524326b55be83b54d4e0ad9",
                "sha256:e263d77ee3dd201c3a142934a086a4450861778baaeeb45db4591ef65550b0a6",
                "sha256:ed9cb427ba5504c1dc15ede7d516b84757c3e3d7868ccc85121d9310d27eed0b",
                "sha256:fa6693661a4c91757f4412306191b6dc88c1703f780c8234035eac011922bc01",
                "sha256:fcd131dd944808b5bdb38e6f5b53013c5aa4f334c5cad0c72742f6eba4b73db0"
            ],
            "version": "==1.15.1"
        },
        "cryptography": {
            "hashes": [
                "sha256:0d09fb5356f975974dbcb595ad2d178305e5050656affb7890a1583f5e02a306",
                "sha256:23c2d778cf829f7d0ae180600b17e9fceea3c2ef8b31a99e3c694cbbf3a24b84",
                "sha256:3fb248989b6363906827284cd20cca63bb1a757e0a2864d4c1682a985e3dca47",
                "sha256:41d7aa7cdfded09b3d73a47f429c298e80796c8e825ddfadc84c8a7f12df212d",
                "sha256:42cb413e01a5d36da9929baa9d70ca90d90b969269e5a12d39c1e0d475010116",
                "sha256:4c2f0d35703d61002a2bbdcf15548ebb701cfdd83cdc12471d2bae80878a4207",
                "sha256:4fd871184321100fb400d759ad0cddddf284c4b696568204d281c902fc7b0d81",
                "sha256:5259cb659aa43005eb55a0e4ff2c825ca111a0da1814202c64d28a985d33b087",
                "sha256:57a51b89f954f216a81c9d057bf1a24e2f36e764a1ca9a501a6964eb4a6800dd",
                "sha256:652627a055cb52a84f8c448185922241dd5217443ca194d5739b44612c5e6507",
                "sha256:67e120e9a577c64fe1f611e53b30b3e69744e5910ff3b6e97e935aeb96005858",
                "sha256:6af1c6387c531cd364b72c28daa29232162010d952ceb7e5ca8e2827526aceae",
                "sha256:6d192741113ef5e30d89dcb5b956ef4e1578f304708701b8b73d38e3e1461f34",
                "sha256:7efe8041897fe7a50863e51b77789b657a133c75c3b094e51b5e4b5cec7bf906",
                "sha256:84537453d57f55a50a5b6835622ee405816999a7113267739a1b4581f83535bd",
                "sha256:8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922",
                "sha256:95dd7f261bb76948b52a5330ba5202b91a26fbac13ad0e9fc8a3ac04752058c7",
                "sha256:a74fbcdb2a0d46fe00504f571a2a540532f4c188e6ccf26f1f178480117b33c4",
                "sha256:a983e441a00a9d57a4d7c91b3116a37ae602907a7618b882c8013b5762e80574",
                "sha256:ab8de0d091acbf778f74286f4989cf3d1528336af1b59f3e5d2ebca8b5fe49e1",
                "sha256:aeb57c421b34af8f9fe830e1955bf493a86a7996cc1338fe41b30047d16e962c",
                "sha256:ce785cf81a7bdade534297ef9e490ddff800d956625020ab2ec2780a556c313e",
                "sha256:d0d651aa754ef58d75cec6edfbd21259d93810b73f6ec246436a21b7841908de"
            ],
            "index": "pypi",
            "version": "==41.0.3"
        },
        "pycparser": {
            "hashes": [
                "sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9",
                "sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206"
            ],
            "version": "==2.21"
        }
    },
    "develop": {}
}

Actual result
Hashes in Pipfile.lock are only for my current OS, where I'm running pipenv install
{
    "_meta": {
        "hash": {
            "sha256": "90025a8184f3365cfb0e9f07920c49ce086e43ac5335361e1ca7a562e9ab9e30"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.10"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "cffi": {
            "hashes": [
                "sha256:39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21",
                "sha256:d400bfb9a37b1351253cb402671cea7e89bdecc294e8016a707f6d1d8ac934f9"
            ],
            "version": "==1.15.1"
        },
        "cryptography": {
            "hashes": [
                "sha256:652627a055cb52a84f8c448185922241dd5217443ca194d5739b44612c5e6507",
                "sha256:6d192741113ef5e30d89dcb5b956ef4e1578f304708701b8b73d38e3e1461f34",
                "sha256:8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922"
            ],
            "index": "pypi",
            "version": "==41.0.3"
        },
        "pycparser": {
            "hashes": [
                "sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9",
                "sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206"
            ],
            "version": "==2.21"
        }
    },
    "develop": {}
}

Steps to replicate
Provide the steps to replicate (which usually at least includes the commands and the Pipfile).

Create a Pipfile

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[requires]
python_version = "3.10"

[packages]
cryptography = "*"

set pipenv version to 2023.7.23
set PIPENV_PYPI_MIRROR to a custom repo
run pipenv install
inspect Pipfile.lock

$ pipenv --support
Pipenv version: '2023.7.23'
Pipenv location: '/Users/foo/.pyenv/versions/3.10.2/lib/python3.10/site-packages/pipenv'
Python location: '/Users/foo/.pyenv/versions/3.10.2/bin/python3.10'
OS Name: 'posix'
User pip version: '21.2.4'
user Python installations found:
PEP 508 Information:
{'implementation_name': 'cpython',
 'implementation_version': '3.10.2',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '22.6.0',
 'platform_system': 'Darwin',
 'platform_version': 'Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:56 PDT '
                     '2023; root:xnu-8796.141.3~6/RELEASE_X86_64',
 'python_full_version': '3.10.2',
 'python_version': '3.10',
 'sys_platform': 'darwin'}

System environment variables:

TERM_PROGRAM
PYENV_ROOT
TERM
SHELL
TMPDIR
TERM_PROGRAM_VERSION
AWS_CREDENTIAL_EXPIRATION
PIP_INDEX_URL
AWS_SESSION_TOKEN
TERM_SESSION_ID
AWS_VAULT
PYENV_VERSION
WORKSPACE
ZSH
USER
COMMAND_MODE
CODEARTIFACT_AUTH_TOKEN
SSH_AUTH_SOCK
PYENV_DIR
__CF_USER_TEXT_ENCODING
PAGER
LSCOLORS
PATH
LaunchInstanceID
AWS_DEFAULT_REGION
COMPOSE_FILES_DIR
__CFBundleIdentifier
PWD
AWS_SECRET_ACCESS_KEY
LANG
ITERM_PROFILE
AWS_REGION
PYENV_HOOK_PATH
XPC_FLAGS
RBENV_SHELL
PIPENV_PYPI_MIRROR
XPC_SERVICE_NAME
AWS_ACCESS_KEY_ID
PYENV_SHELL
SHLVL
HOME
COLORFGBG
LC_TERMINAL_VERSION
ITERM_SESSION_ID
LESS
LOGNAME
LC_TERMINAL
SECURITYSESSIONID
SQLITE_EXEMPT_PATH_FROM_VNODE_GUARDS
ASDF_HASHICORP_TERRAFORM_VERSION_FILE
COLORTERM
PYTHONDONTWRITEBYTECODE
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:

PIPENV_PYPI_MIRROR: https://aws:....codeartifact.us-east-2.amazonaws.com/pypi/foo-python/simple/

Debug–specific environment variables:

PATH: /Users/foo/.pyenv/versions/3.8.7/bin:/Users/foo/.pyenv/versions/3.9.13/bin:/Users/foo/.pyenv/versions/3.10.2/bin:/Users/foo/.pyenv/versions/3.9.10/bin:/Users/foo/.pyenv/versions/3.8.10/bin:/Users/foo/.pyenv/versions/3.10.2/bin:/usr/local/Cellar/pyenv/2.3.16/libexec:/usr/local/Cellar/pyenv/2.3.16/plugins/python-build/bin:/Users/foo/.pyenv/shims:/Users/foo/bin:/Users/foo/.pyenv/bin:/Users/foo/.rbenv/shims:/Users/foo/bin:/Users/foo/.pyenv/bin:/Users/foo/.rbenv/shims:/Users/foo/.pyenv/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/foo/.asdf/shims:/Users/foo/.asdf/shims
SHELL: /bin/zsh
LANG: en_US.UTF-8

Contents of Pipfile ('/Users/foo/workspace/foo-test-cryptograph-all-platform-hashes/Pipfile'):
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[requires]
python_version = "3.10"

[packages]
cryptography = "*"

Contents of Pipfile.lock ('/Users/foo/workspace/foo-test-cryptograph-all-platform-hashes/Pipfile.lock'):
{
    "_meta": {
        "hash": {
            "sha256": "90025a8184f3365cfb0e9f07920c49ce086e43ac5335361e1ca7a562e9ab9e30"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.10"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "cffi": {
            "hashes": [
                "sha256:39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21",
                "sha256:d400bfb9a37b1351253cb402671cea7e89bdecc294e8016a707f6d1d8ac934f9"
            ],
            "version": "==1.15.1"
        },
        "cryptography": {
            "hashes": [
                "sha256:652627a055cb52a84f8c448185922241dd5217443ca194d5739b44612c5e6507",
                "sha256:6d192741113ef5e30d89dcb5b956ef4e1578f304708701b8b73d38e3e1461f34",
                "sha256:8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922"
            ],
            "index": "pypi",
            "version": "==41.0.3"
        },
        "pycparser": {
            "hashes": [
                "sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9",
                "sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206"
            ],
            "version": "==2.21"
        }
    },
    "develop": {}
}

@jermbop Could you check this on:  https://github.com/pypa/pipenv/pull/5793
Planning to merge that this month and it will be important to know if what you are describing is an issue with that branch as well.  If it is, I think I need more details about what you mean by custom repo.

@matteius I followed the steps from https://github.com/pypa/pipenv/pull/5793#issuecomment-1673106683 to install your version.  I confirmed the version is set to
pipenv --version
pipenv, version 2023.7.24.dev0

I'm still seeing the same issue where the Pipfile.lock only has hashes for my OS.
For our custom repo we are setting PIPENV_PYPI_MIRROR and pulling through AWS's Codeartifact

@jermbop I see, using a private index -- question, is there a recent prior version of pipenv that was resolving all hashes for a private index?

I am also seeing this with version 2023.7.23 while using the extra index https://download.pytorch.org/whl/cpu to install torch. Downgrading to version 2023.7.9 has fixed the problem.

@matteius
@boonware and I are seeing the same behavior. 2023.7.9 works for me as well.

I was able to get this sorted on the draft-no-reqslib branch and pushed up some small changes based on my testing.
INFO:pipenv.patched.pip._internal.network.download:Using cached requests-2.31.0-py3-none-any.whl (62 kB)
INFO:pipenv.patched.pip._internal.network.download:Using cached certifi-2023.7.22-py3-none-any.whl (158 kB)
INFO:pipenv.patched.pip._internal.network.download:Using cached charset_normalizer-3.2.0-cp38-cp38-win_amd64.whl (96 kB)
INFO:pipenv.patched.pip._internal.network.download:Using cached urllib3-2.0.4-py3-none-any.whl (123 kB)
INFO:pipenv.patched.pip._internal.network.download:Using cached typing_extensions-4.7.1-py3-none-any.whl (33 kB)
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp36-cp36
m-linux_x86_64.whl to obtain hash...
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp36-cp36
m-win_amd64.whl to obtain hash...
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp37-cp37
m-linux_x86_64.whl to obtain hash...
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp37-cp37
m-win_amd64.whl to obtain hash...
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp38-cp38
-linux_x86_64.whl to obtain hash...
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp38-cp38
-win_amd64.whl to obtain hash...
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp39-cp39
-linux_x86_64.whl to obtain hash...
Downloading file
https://download.pytorch.org/whl/cu111/whl/cu111/torch-1.10.2%2Bcu111-cp39-cp39
-win_amd64.whl to obtain hash...
[ ===] Locking...
Success!
Locking [dev-packages] dependencies...
Updated Pipfile.lock (c0a33c165f07d81030173ceeabab4a677a39b73dabb7de87af1ed11b6cf3b709)!

        "torch": {
            "hashes": [
                "sha256:0b4b32831aca1761be49a1d584d509f02d03bc6108c114972b4457a971007e9a",
                "sha256:3828d951c5a6e78d0b0a4edc1cfd21f7319ce08650cd68a605169e60aa33ddf9",
                "sha256:7bc0d93f1fb20618ac3aa793ef74c7b8800a065d2d5dd09284846cb0f6154b25",
                "sha256:9cfc57dd2b3ac6832e87ac7f5bf2cf2809ce00f08978a6c91d0f021b395d42ec",
                "sha256:a9119bf83a3c2b98c6a40b31102fca359fb2c875d328ace7a4b80d2223a2a9d6",
                "sha256:b3e301dea27fdc7f6534231adf91d8df5d6b9754186feafbe145e5bd57b857a8",
                "sha256:c20b57584a7fd7d5487ebd29a812b922e6831967a6e5ea3738f038d232793923",
                "sha256:c5241543c3c9667bca8d99e49d1de6392a89803bedf4f1e4fb758ab08366b4cc"
            ],
            "index": "downloadpytorch",
            "version": "==1.10.2+cu111"
        },

I seem to have your latest commit -> Resolved https://github.com/pypa/pipenv.git to commit 8a62691fc0237fe4c9d61226393c2529a7c13ebc
I'm still seeing the same behavior where my Pipfile.lock only has hashes for my OS.

@matteius
https://pipenv-fork.readthedocs.io/en/latest/advanced.html#using-a-pypi-mirror
To my understanding I can either run pipenv install --pypi-mirror <mirror_url> or set PIPENV_PYPI_MIRROR.  I did test the former command and am seeing the same outcome.  When I downgrade to 2023.7.9 PIPENV_PYPI_MIRROR is working as expected.

@jermbop thats a different docs link, I think it would be this one:  https://pipenv.pypa.io/en/latest/indexes/#using-a-pypi-mirror

To my understanding I can either run pipenv install --pypi-mirror <mirror_url> or set PIPENV_PYPI_MIRROR.

Yes that is correct, but my suspicion is that is also where there may still be a bug.  Since I do not have access to your private pypi mirror, its harder for me to test this which is why I am asking if you can try to not use the pypi-mirror in testing my branch and instead change the Pipfile or lockfile source URL to be the mirror and run a couple checks.   This will help me determine:

Is it just a bug with pypi-mirror (ok we can look more deeply into that if so) OR
Is it perhaps something isn't matching when we scrape the index for the hashes.

Its not really going to be too useful for me to test on main/current release because my future looking branch is likely to get merged soon, and so I'll want to find the path forward from starting from that code.   Nothing stood out to me comparing 2023.7.11 to 2023.7.9 anyway and plus a lot more fixes in the draft-no-reqlib branch including the fix from today that I verified against the pytorch index.
Just to reiterate, I think there is a bug and it should be fixed, but it somewhat non-trivial and so some help pin-pointing it will help me do a better job with it.

@matteius  I removed PIPENV_PYPI_MIRROR from my env vars, updated the Pipfile source, and captured the lockfile and verbose output.
Pipfile
[[source]]
url = "https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/"

verify_ssl = true
name = "pypi"

[requires]
python_version = "3.10"

[packages]
cryptography = "*"

Pipfile.lock

```
{
    "_meta": {
        "hash": {
            "sha256": "f4733ffb52d998353d78a421bddc36b09d51a95a6779f203cf18c248734cd676"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.10"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "cffi": {
            "hashes": [
                "sha256:39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21",
                "sha256:d400bfb9a37b1351253cb402671cea7e89bdecc294e8016a707f6d1d8ac934f9"
            ],
            "version": "==1.15.1"
        },
        "cryptography": {
            "hashes": [
                "sha256:652627a055cb52a84f8c448185922241dd5217443ca194d5739b44612c5e6507",
                "sha256:6d192741113ef5e30d89dcb5b956ef4e1578f304708701b8b73d38e3e1461f34",
                "sha256:8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922"
            ],
            "index": "pypi",
            "markers": "python_version >= '3.7'",
            "version": "==41.0.3"
        },
        "pycparser": {
            "hashes": [
                "sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9",
                "sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206"
            ],
            "version": "==2.21"
        }
    },
    "develop": {}
}
```

Verbose output of pipenv install -v --dev

```
pipenv install -v --dev
Using python: 3.10
Path to python: /Users/myusername/.pyenv/versions/3.10.2/bin/python3
Creating a virtualenv for this project...
Pipfile: /Users/myusername/workspace/test-cryptograph-all-platform-hashes/Pipfile
Using /Users/myusername/.pyenv/versions/3.10.2/bin/python3 (3.10.2) to create virtualenv...
⠇ Creating virtual environment...created virtual environment CPython3.10.2.final.0-64 in 474ms
  creator CPython3Posix(dest=/Users/myusername/.local/share/virtualenvs/test-cryptograph-all-platform-hashe-eEkz4Ddq, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/Users/myusername/Library/Application Support/virtualenv)
    added seed packages: pip==23.2.1, setuptools==68.0.0, wheel==0.41.1
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
✔ Successfully created virtual environment!
Virtualenv location: /Users/myusername/.local/share/virtualenvs/test-cryptograph-all-platform-hashe-eEkz4Ddq
Pipfile.lock not found, creating...
Locking [packages] dependencies...
Building requirements...
Resolving dependencies...
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting()
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.adding_requirement(SpecifierRequirement('cryptography'), None)
INFO:pipenv.patched.pip._internal.operations.prepare:Collecting cryptography (from -r
/var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-4fy8295n-requirements/pipenv-r6w40273-constraints.txt (line 2))
INFO:pipenv.patched.pip._internal.network.download:Using cached
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x86_64.whl (2.8
MB)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(0)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.adding_requirement(SpecifierRequirement('cffi>=1.12'),
LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x8
6_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))
INFO:pipenv.patched.pip._internal.operations.prepare:Collecting cffi>=1.12 (from cryptography->-r
/var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-4fy8295n-requirements/pipenv-r6w40273-constraints.txt (line 2))
INFO:pipenv.patched.pip._internal.network.download:Using cached
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl (179 kB)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.pinning(LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x86_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending_round(0, state)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(1)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.adding_requirement(SpecifierRequirement('pycparser'),
LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256
=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)'))
INFO:pipenv.patched.pip._internal.operations.prepare:Collecting pycparser (from cffi>=1.12->cryptography->-r
/var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-4fy8295n-requirements/pipenv-r6w40273-constraints.txt (line 2))
INFO:pipenv.patched.pip._internal.network.download:Using cached
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.whl (118 kB)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.pinning(LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending_round(1, state)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(2)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.pinning(LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.whl#sha256=8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending_round(2, state)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(3)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending(State(mapping=OrderedDict([('cryptography',
LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x8
6_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)')), ('cffi',
LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256
=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)')), ('pycparser',
LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.whl#sha256=8ee4542
9555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/)'))]), criteria={'cryptography':
Criterion((SpecifierRequirement('cryptography'), via=None)), 'cffi': Criterion((SpecifierRequirement('cffi>=1.12'),
via=LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_1
2_x86_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))), 'pycparser':
Criterion((SpecifierRequirement('pycparser'),
via=LinkCandidate('https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sh
a256=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)')))}, backtrack_causes=[]))
⠋ Locking...
✔ Success!
Locking [dev-packages] dependencies...
Updated Pipfile.lock (f4733ffb52d998353d78a421bddc36b09d51a95a6779f203cf18c248734cd676)!
Installing dependencies from Pipfile.lock (4cd676)...
Writing supplied requirement line to temporary file: 'cffi==1.15.1 --hash=sha256:39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21
--hash=sha256:d400bfb9a37b1351253cb402671cea7e89bdecc294e8016a707f6d1d8ac934f9'
Writing supplied requirement line to temporary file: "cryptography==41.0.3; python_version >= '3.7' --hash=sha256:652627a055cb52a84f8c448185922241dd5217443ca194d5739b44612c5e6507
--hash=sha256:6d192741113ef5e30d89dcb5b956ef4e1578f304708701b8b73d38e3e1461f34 --hash=sha256:8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922"
Writing supplied requirement line to temporary file: 'pycparser==2.21 --hash=sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9
--hash=sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206'
Install Phase: Standard Requirements
Preparing Installation of 'cffi==1.15.1 --hash=sha256:39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21
--hash=sha256:d400bfb9a37b1351253cb402671cea7e89bdecc294e8016a707f6d1d8ac934f9'
Preparing Installation of "cryptography==41.0.3; python_version >= '3.7' --hash=sha256:652627a055cb52a84f8c448185922241dd5217443ca194d5739b44612c5e6507
--hash=sha256:6d192741113ef5e30d89dcb5b956ef4e1578f304708701b8b73d38e3e1461f34 --hash=sha256:8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922"
Preparing Installation of 'pycparser==2.21 --hash=sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9
--hash=sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206'
$ /Users/myusername/.local/share/virtualenvs/test-cryptograph-all-platform-hashe-eEkz4Ddq/bin/python
/Users/myusername/.pyenv/versions/3.10.2/lib/python3.10/site-packages/pipenv/patched/pip/pip-runner.py install -i
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/ --no-input --upgrade --no-deps -r /var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-idg8eukk-requirements/pipenv-jngmouuh-hashed-reqs.txt
Using source directory: '/Users/myusername/.local/share/virtualenvs/test-cryptograph-all-platform-hashe-eEkz4Ddq/src'
Looking in indexes: https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/
Collecting cffi==1.15.1 (from -r /var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-idg8eukk-requirements/pipenv-jngmouuh-hashed-reqs.txt (line 1))
Using cached https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl (179
kB)
Collecting cryptography==41.0.3 (from -r /var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-idg8eukk-requirements/pipenv-jngmouuh-hashed-reqs.txt (line 2))
Using cached
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x86_64.whl (2.8
MB)
Collecting pycparser==2.21 (from -r /var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-idg8eukk-requirements/pipenv-jngmouuh-hashed-reqs.txt (line 3))
Using cached https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.whl (118 kB)
Installing collected packages: cffi, pycparser, cryptography
Successfully installed cffi-1.15.1 cryptography-41.0.3 pycparser-2.21
Install Phase: Editable Requirements
Preparing Installation of 'cffi==1.15.1 --hash=sha256:39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21
--hash=sha256:d400bfb9a37b1351253cb402671cea7e89bdecc294e8016a707f6d1d8ac934f9'
Preparing Installation of "cryptography==41.0.3; python_version >= '3.7' --hash=sha256:652627a055cb52a84f8c448185922241dd5217443ca194d5739b44612c5e6507
--hash=sha256:6d192741113ef5e30d89dcb5b956ef4e1578f304708701b8b73d38e3e1461f34 --hash=sha256:8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922"
Preparing Installation of 'pycparser==2.21 --hash=sha256:8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9
--hash=sha256:e644fdec12f7872f86c58ff790da456218b10f863970249516d60a5eaca77206'
$ /Users/myusername/.local/share/virtualenvs/test-cryptograph-all-platform-hashe-eEkz4Ddq/bin/python
/Users/myusername/.pyenv/versions/3.10.2/lib/python3.10/site-packages/pipenv/patched/pip/pip-runner.py install -i
https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/ --no-input --upgrade --no-deps -r /var/folders/6n/cgk3c7pn3kg97b5md65vw7bw0000gp/T/pipenv-idg8eukk-requirements/pipenv-oi0mf3fl-reqs.txt
Using source directory: '/Users/myusername/.local/share/virtualenvs/test-cryptograph-all-platform-hashe-eEkz4Ddq/src'
Looking in indexes: https://aws:{ourToken}@{ourCustomDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/
Installing dependencies from Pipfile.lock (4cd676)...
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.
</details>

@jermbop thanks for the output, while 8a62691fc0237fe4c9d61226393c2529a7c13ebc is the commit  hash of my latest commit, something isn't adding up with the output, because I added a err.print (rich stderr print) statement to the common function get_file_hash ... I truly believe it should log at least once "Downloading file {link.filename} to obtain hash..." for the hash it did obtain.  🤔   Although ...
There is logic to get the hash from the url of the package link from the index page if its available.   Are you able to determine if the hashes are in the your index links (usually as query parameters at the end of the URLs).  Also, are you sure that your private mirror has multiple wheels of the same package version for different platforms that it would be able to obtain?   If not, it may be possible it was actually getting those extra hashes from pypi before ... really hard to make a determination yet.

@matteius
I tested again with version 2023.7.9.  I have both the Pipfile source url and PIPENV_PYPI_MIRROR pointing to our custom index.  I also included a snapshot of our custom indexes assets for cryptography.  It includes all hashes.  Please let me know if there's anything you'd like me to run or test out.
Output of install with version 2023.7.9

pipenv install -v --dev
Pipfile.lock not found, creating...
Locking [packages] dependencies...
Building requirements...
Resolving dependencies...
Reporter.starting()
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting()
Reporter.adding_requirement(SpecifierRequirement('cryptography'), None)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.adding_requirement(SpecifierRequirement('cryptography'), None)
Reporter.starting_round(0)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(0)
Reporter.adding_requirement(SpecifierRequirement('cffi>=1.12'),
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x8
6_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.adding_requirement(SpecifierRequirement('cffi>=1.12'),
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x8
6_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))
Reporter.pinning(LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi
3-macosx_10_12_x86_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.pinning(LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/beac
on-python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x86_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))
Reporter.ending_round(0, state)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending_round(0, state)
Reporter.starting_round(1)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(1)
Reporter.adding_requirement(SpecifierRequirement('pycparser'),
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256
=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.adding_requirement(SpecifierRequirement('pycparser'),
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256
=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)'))
Reporter.pinning(LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_
x86_64.whl#sha256=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.pinning(LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/beac
on-python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)'))
Reporter.ending_round(1, state)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending_round(1, state)
Reporter.starting_round(2)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(2)
Reporter.pinning(LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.w
hl#sha256=8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/)'))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.pinning(LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/beac
on-python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.whl#sha256=8ee45429555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/)'))
Reporter.ending_round(2, state)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending_round(2, state)
Reporter.starting_round(3)
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.starting_round(3)
Reporter.ending(State(mapping=OrderedDict([('cryptography',
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x8
6_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)')), ('cffi',
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256
=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)')), ('pycparser',
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.whl#sha256=8ee4542
9555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/)'))]), criteria={'cryptography':
Criterion((SpecifierRequirement('cryptography'), via=None)), 'cffi': Criterion((SpecifierRequirement('cffi>=1.12'),
via=LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_1
2_x86_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))), 'pycparser':
Criterion((SpecifierRequirement('pycparser'),
via=LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sh
a256=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)')))}, backtrack_causes=[]))
INFO:pipenv.patched.pip._internal.resolution.resolvelib.reporter:Reporter.ending(State(mapping=OrderedDict([('cryptography',
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_12_x8
6_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)')), ('cffi',
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sha256
=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)')), ('pycparser',
LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/2.21/pycparser-2.21-py2.py3-none-any.whl#sha256=8ee4542
9555515e1f6b185e78100aea234072576aa43ab53aefcae078162fca9 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/pycparser/)'))]), criteria={'cryptography':
Criterion((SpecifierRequirement('cryptography'), via=None)), 'cffi': Criterion((SpecifierRequirement('cffi>=1.12'),
via=LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/41.0.3/cryptography-41.0.3-cp37-abi3-macosx_10_1
2_x86_64.whl#sha256=8f09daa483aedea50d249ef98ed500569841d6498aa9c9f4b0531b9964658922 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cryptography/) (requires-python:>=3.7)'))), 'pycparser':
Criterion((SpecifierRequirement('pycparser'),
via=LinkCandidate('https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/1.15.1/cffi-1.15.1-cp310-cp310-macosx_10_9_x86_64.whl#sh
a256=39d39875251ca8f612b6f33e6b1195af86d1b3e60086068be9cc053aa4376e21 (from
https://{ourCustomerDomain}.d.codeartifact.us-east-2.amazonaws.com/pypi/python/simple/cffi/)')))}, backtrack_causes=[]))
⠼ Locking...
✔ Success!
Locking [dev-packages] dependencies...
Updated Pipfile.lock (90025a8184f3365cfb0e9f07920c49ce086e43ac5335361e1ca7a562e9ab9e30)!
Installing dependencies from Pipfile.lock (ab9e30)...
Installing dependencies from Pipfile.lock (ab9e30)...
To activate this project's virtualenv, run pipenv shell.
Alternatively, run a command inside the virtualenv with pipenv run.

Thanks @jermbop -- that does indicate the URLs have the sha256 hashes as query parameters -- we can dig in more if its still broken, but I cut release 2023.8.19 and would be good confirm to its still broken before we dig deeper.   I would also be open to scheduling a debugging session if possible.

@matteius Just tested with 2023.8.19.  I'm still seeing the same issue.  I'm open for a debugging session!

@jermbop I may have some time next weekend given its calling for rain here.   If you click on my github profile, I have my email you can send me and I can invite you to a python developers slack group ...

This is related also to my bug https://github.com/pypa/pipenv/issues/5894

I am hopeful that 2023.9.1 solves this for you @jermbop since it did for @matejsp's example.

@matteius I tested changes from your branch issue-5827-compat (version 2023.9.2.dev0).  This branch correctly installs all platform hashes!  Thanks for your work on this.  When a release is cut I can test again, making sure it works for the release

2023.9.7 included this change.

Thanks!!
On Thu, Sep 7, 2023, 10:38 AM Matt Davis @.***> wrote:

2023.9.7 included this change.
—
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/5827#issuecomment-1710377161, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AC4M4INBFYBKVPZVKLQ2TMLXZHS7VANCNFSM6AAAAAA3NIY24E
.
You are receiving this because you were mentioned.Message ID:
@.***>

authors: boonware jermbop matejsp matteius


text:
setup.cfg doesn't appear to support py_modules=?

If this is a PEBKAC and I just did something wrong, let me know.  I have a single file python module I wanted to distribute.  I found my way through the maze of twisty passages to enough information for me to believe I could do so without a setup.py file.  not quite.
setup(py_modules=['modulename']) properly packages modulename.py.
But removing that parameter and adding this to setup.cfg:
[options]
py_modules = modulename

Does not.  modulename.py is missing from the package in that scenario.

nevermind, it was a PEBKAC, sorry for the issue spam.  I don't know why it wasn't working for me last night.  typos on my part?  not requiring a recent enough setuptools?  i didn't save the unworking file so i'll never know.
putting py_modules= in [options] within setup.cfg and requiring setuptools >= 40.9.0 in my pyproject.toml is working.  time to delete setup.py!  :)
https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files

source: gharchive/issue

repo: pypa/setuptools

license: mit

license_type: permissive

license_source: bigquery


text:
Remove test command and tests_require

In this comment, @graingert proposes that we may be able to completely remove support for tests_require instead of transitioning that tooling from easy_install to pip install.
While he didn't directly propose removal, the effort would only benefit that ticket if the install functionality were completely removed, so let's explore what that will entail.
While I agree that tox is an excellent, powerful, robust solution, it's more heavy than tests_require, requiring that the user have tox installed in advance. As a more thorough solution, it also is subject to bugs and constraints that a simpler test runner is not. There are several advantages to setup.py test and tests_require over tox:

Doesn't have any prerequisites (except the implicit one on Setuptools, which is generally assumed).
As a result of not having any prerequisites, invocation is often a simple invocation (setup.py test) instead of multiple steps (e.g. pip install --user tox; python -m tox).
setup.py test allows for invocation under a number of different Python versions naturally (i.e. python3.3 setup.py test or py -3.3 setup.py test) whereas tox offers "run under the python in which tox is installed" or "run for explicitly-declared python versions".
As setup.py test doesn't use virtualenv, it's not subject to virtualenv bugs or other constraints imposed by virtualenv (such as version 14 dropping support for Python 3.2.).
As setup.py test doesn't rely on pip, it's not subject to the bugs of pip (such as issues with --editable installs or namespace packages) or other constraints imposed by pip (such as dropping support for Python 3.2).

I consider these advantages small and easy enough to overcome, especially now that many of these issues have been resolved in setuptools, pip, and virtualenv. If we can get to a place that tox can broadly supplant the uses cases of setup.py test and pytest-runner (and thus tests_require) in practice, then yes, deprecating and removing it would be in order. Given the amount of activity and bugs I see around these tools, I'd asses they're still in active use.
Before flagging this functionality as deprecated, I'd like to survey the community about the possibility to see if there are use cases that would prove difficult to support with tox.
@graingert, would you be interested in being the champion for this effort (removing tests_require), starting with the outreach on distutils-sig and then implementing the deprecation/removal changes?

Perhaps its relevant here. After discussing with @RonnyPfannschmidt we added the following to the Tox docs.

Integrating tox with setup.py test is as of October 2016 discouraged as it breaks packaging/testing approaches as used by downstream distributions which expect setup.py test to run tests with the invocation interpreter rather than setting up many virtualenvs and installing packages. If you need to define setup.py test you can better see about integrating your eventual test runner with it, here is an example of setup.py test integration with pytest. As the python eco-system rather moves away from using setup.py as a tool entry point it’s maybe best to not go for any setup.py test integration.

As a downstream we prefer to have one command that tests the package for the interpreter that is available and not any other versions.

I've discovered that tox -e py or tox -e python will test against the python in which tox is installed, and in fact that's the default behavior if no envlist is provided. I use this usage by default across dozens of projects and find it quite useful.

Yes, I agree, as long as no other envs are defined, then there's no problem.

tox is good for CI, but too unwieldy for development. There should be an easy and intuitive way to run single test. Then this way can be combined with filesystem watcher of your choice.

@techtonik tox works totally fine for dev, you can use {pos args} to pass test flags to pytest: tox -e py36 -- --cov -s etc

@graingert how much time does it take on you system to execute a single test with tox. On my it takes more than 5 seconds, which is not acceptable. Also, tox doesn't support output redirection, which makes debugging hard.

@jaraco instead of test_requires, i'd like to see something that allows pip install -e .[test]

I don't like the idea of replacing simple test calling with tox with my openSUSE Python maintenance hat on. We strive hard to achieve reproducible builds in openSUSE and thus we strongly prefer packages with small dependency trees. osc dependson openSUSE:Factory python-tox standard x86_64|grep python-|wc -l gives me 33 dependent packages (there are some false positives) and that seems too many for tool which should end up as a dependency of setuptools (or be on the same level in the dependency tree). We would probably have to eliminate all python setup.py test calls with something more primitive (e.g., python -munittest discover if you don't plan to eliminate that as well), but that seems counterproductive.

I don't like the idea of replacing simple test calling with tox with my openSUSE Python maintenance hat on. We strive hard to achieve reproducible builds in openSUSE and thus we strongly prefer packages with small dependency trees.

To be clear, tox is not installed in the environment that actually runs the tests (unless you specifically want that). It manages virtual environments that have exactly the dependencies you want installed and nothing more. I suspect that this will give you fewer dependencies during the run, not more.

We would probably have to eliminate all python setup.py test calls with something more primitive (e.g., python -munittest discover if you don't plan to eliminate that as well), but that seems counterproductive.

Eliminate where or how? For your own projects or for projects you are packaging? tox is similar to make test in that each project can specify its own test commands. python -munittest discover will not work for a large number of packages, which intend for you to use pytest, and presumably also intend to have the dependencies that tox installs.

Eliminate where or how? For your own projects or for projects you are packaging? tox is similar to make test in that each project can specify its own test commands. python -munittest discover will not work for a large number of packages, which intend for you to use pytest, and presumably also intend to have the dependencies that tox installs.

Well, the problem with whole virtual environments tox promotes is that it is completely useless in the Linux packaging world: we have all builds working in their own chrooted completely isolated environments so whatever issues virtenv is trying to solve are completely irrelevant for us. Also, we have different mechanisms (full blown isolated builds in separate virtual machines or something of that calibre) for testing with different versions of Python or something.
So, we usually end up with digging into tox.ini and ripping out only unittest (or pytest, it doesn't matter) line and using only that.

@mcepl Well, in that case I think then tox is not actually necessary, since tox is just doing the part that you are doing manually anyway (e.g. setting up the dependencies and environment, then running the tests).
One nice thing about the very declarative nature of tox is that it would probably not be terribly difficult for you to write a script that parses tox.ini and creates your preferred type of build file from it (subject to adjustment since you'd need to map the names of PyPI dependencies to your own system).
In any case, fewer and fewer projects are actually using setup.py test because of the problem of dependency management, so likely deprecating setup.py will create less work for you, since you wouldn't need to support both projects using tox and projects using setup.py test (and extracting tests_require from a non-declarative setup.py file, etc).

@mcepl Well, in that case I think then tox is not actually necessary, since tox is just doing the part that you are doing manually anyway (e.g. setting up the dependencies and environment, then running the tests).

That's exactly what I’ve meant, so general feeling that more and more projects rely on tox more heavily makes me a bit uneasy. And yes, setup.py test is probably just more a calling convention than anything useful. We usually rather use pytest directly (even for nose- and unittest- based test suites).

tox is designed to build and test the package in all Python versions that it officially supports. While setup.py test is supposed to run tests, in the running Python version, assuming the build has already been done.
So, they are doing massively different things. To get comparable experience, a user needs to somehow figure out which tox environment specified ini tox.ini corresponds to the running Python (if there even is such an environment -- tox only supports official CPython releases AFAICS) and pass it to tox -e.

@native-api None of these things are true. While tox is very useful for parametrizing over different Python versions, it is trivial to use the current interpreter, it's even mentioned in this issue: tox -e py.
It certainly supports pypy in the normal parametrized list of environments.
Yes there are differences between tox and setup.py test, because tox does what setup.py test should do.

@pganssle
None of these things are true.

+1 for the explanations. It's not in the reference documentation so I had no way to know this. (The whole purpose of a reference is to be a complete list of the project's official guarantees.)

In Nixpkgs the default Python builder (that expects setuptools-based projects) runs python setup.py test. Fewer projects implement it nowadays so we typically have to override it. Hopefully soon we can switch the default builder to use pyproject. In that case, we don't have any default command for the test phase, because nothing has been defined and nothing common exists, although it is tempting to just run pytest by default (bootstrapping is a bit more difficult then though).
I can understand the motivation for using Tox, but I suggest that at this point it makes more sense to standardize by going through a PEP. PEP 517/518 is a big improvement, and getting testing included there as well is where we should be going.

Looks like tox is toxic, because it can not be used without adding a vendor lockin.
Quick <1s test runs for TTD in IDEs that support test-on-edit and using tox for a slow, heavy and thorough CI testing should not be mutually exclusive options.

its not ..

I can understand the motivation for using Tox, but I suggest that at this point it makes more sense to standardize by going through a PEP. PEP 517/518 is a big improvement, and getting testing included there as well is where we should be going.

You are welcome to write a draft PEP for this. I suspect that such a thing would be welcomed. I think the reason there has been no clear spec for this is that it's not very common for end users to run a project's tests - usually the people who run the tests are the developers of the package themselves and certain downstream redistributors. The package developers usually have to manually configure CI to run their tests and they don't have to do this at scale, so a standard is less necessary. The redistributors tend to be testing their whole package ecosystem, which means that something defined in terms of the PyPI package ecosystem will still need manual intervention, reducing the need for any sort of standard.
Still, if you and other downstream redistributors of Python packages would like to propose such a standard, I recommend doing so. I think the packaging category or the users category on the Python discourse would be a good place to start. I think you will get a better response if you come in with a concrete proposal rather than creating a general "brainstorming" topic, but that is just my experience with posting such things.

Discussion on Python Packaging discourse about a section in pyproject.toml.
https://discuss.python.org/t/proposal-for-tests-entry-point-in-pyproject-toml/2077

I have difficulties following the thought that tox would be the right standard tool to run tests. I like tox, but it is the tool for creating virtual environments and then to invoke a tool that runs tests.
What I am missing most is an ability to include the test files in a package (i.e. the test files, not a specification of their additional package dependencies). In https://github.com/pypa/setuptools/issues/1684, @pganssle said:

I personally still recommend that you include your test code in your sdist, but not in the wheel.
How can that be achieved?

If I understand your question correctly, in case you have tests in a separate dir, you can include them in MANIFEST.in, e.g.
include tests/*.py

I personally still recommend that you include your test code in your sdist, but not in the wheel.

How can that be achieved?

McSinyx' suggestion to include them in MANIFEST.in is one way. Another is to use a tool like setuptools_scm to always include all of your source files from your repo in your sdist. See the keyring project for an example of tests that get included with the sdist but aren't installed.

Is it possible to define tests files directly in pyproject.toml? Something like:
exclude = {{ tests.files }}

[tests.files]
tests/*.py

And FWIW, the dependencies to run them:
[tests.requirements]
pytest
[tests.requirements:py2]
six

And the command to run:
[tests.command]
pytest {{ args }}

Or what would be the correct syntax?
If the data is defined this way, then:

packaging tool can exclude the test from packing
IDE can find the requirements, match them against specific Python interpreter and exec the right command

Yes, you can use tool.pytest.ini_options https://docs.pytest.org/en/latest/customize.html#pyproject-toml

Admittedly I am coming late to this discussion. But the deprecation warning escaped my attention for a long time as it precedes all the other output during testing. If I see all the tests passing I don't scroll up to search for deprecation messages.
As far as I can judge tox complicates the use of the already complicated setuptools even further. I am therefore unhappy with the deprecation of the test command, which is working fine for me. It feels to me like imposing a standard suitable for packages supported by large teams, which doesn't fit other usecases.
What makes deprication desirable? Are there large costs involved in keeping it up and running? Because there are also costs involved in adapting to this change, mainly for developers who are not experts on Python distribution and testing, and don't work in a large team.

What makes deprication desirable?

See OP.

Are there large costs involved in keeping it up and running?

Yes. test depends on tests_requires which depends on easy_install which depends on old, insecure, and unsupported behavior.

Could we split this ticket into two, please?
a) “Remove test command and test_require …”, and
b) “in favour of tox”
I agree with the first one. But could we still keep supported “python setup.py build && some-kind-of-runner” as well (for nosetest2/pytest/python -munittest discover)?

What makes deprication desirable?

See OP.

The OP only states minor advantages of setup test.  But I understand there are maintenance costs now.
@mcepl's suggestion of having some possibility to run the existing tests now discovered by the test command directly from setup using another method under the hood would mitigate the negative impact.

Could we split this ticket into two, please?

There is no need to split the ticket into two. From our perspective, the important part is that python setup.py test goes away, and we no longer support running it. We recommend tox because that basically does a better job of solving the same problem, but you are welcome to use whatever test runner you want.
#1878 was merged October 22, 2019, which was released as part of 41.5.0 on October 27, 2019.
I think we should go ahead and target the removal of setup.py test for approximately 1 year after the deprecation (which is at the end of next month).

Could the removal be done in two steps? First, remove the dependency resolving part. And then later, the actual test execution part. If I am correct the main maintenance issue is the resolving part, which I absolutely agree with that should disappear.
The reason I am suggesting this is that distro's (speaking here as Nixpkgs maintainer) will provide the dependencies themselves anyway, but a significant part (I guess a third or so, rough guess) of all Python packages still use setup.py test for testing.

Wasting my time trying to overcome this change. I don't understand why you can't remove the dependency part while keeping the test runners. What is their relation? To me they are two entirely different things.

Wasting my time trying to overcome this change. I don't understand why you can't remove the dependency part while keeping the test runners. What is their relation? To me they are two entirely different things.

Workaround for nose2 using the ability to define your own commands. It can probably be adapted for other testsuites.
The OnSuccess nose2 plugin can be edited out, but it provides me with the ability to remove log-files generated during testing. Only imports specific to this solution are shown.
from setuptools import Command
import nose2
from nose2.events import Plugin

class OnSuccess(Plugin):
    def wasSuccessful(self, event):
        if event.success:
            print('Success!')
        else:
            print('Failure!')

class nose2Testing(Command):
    """ Run my command.
    """
    description = 'nose2testing'

    user_options = []  # obligatory

    def initialize_options(self):
        self.onsuccesshook = OnSuccess()
        print('initialize_options')

    def finalize_options(self):
        print('finalize_options')

    def run(self):
        nose2.discover(argv=['.'], exit=False, extraHooks=[('wasSuccessful',self.onsuccesshook)])

if __name__ == "__main__":
    setup(
        ...
        cmdclass={
                'nose2': nose2Testing,
            },
    )

Workaround for nose2 using the ability to define your own commands. It can probably be adapted for other testsuites.
The OnSuccess nose2 plugin can be edited out, but it provides me with the ability to remove log-files generated during testing. Only imports specific to this solution are shown.
from setuptools import Command
import nose2
from nose2.events import Plugin

class OnSuccess(Plugin):
    def wasSuccessful(self, event):
        if event.success:
            print('Success!')
        else:
            print('Failure!')

class nose2Testing(Command):
    """ Run my command.
    """
    description = 'nose2testing'

    user_options = []  # obligatory

    def initialize_options(self):
        self.onsuccesshook = OnSuccess()
        print('initialize_options')

    def finalize_options(self):
        print('finalize_options')

    def run(self):
        nose2.discover(argv=['.'], exit=False, extraHooks=[('wasSuccessful',self.onsuccesshook)])

if __name__ == "__main__":
    setup(
        ...
        cmdclass={
                'nose2': nose2Testing,
            },
    )

@RonaldAJ Glad you found a workaround. Note that Setuptools also supports defining that command as a plugin, in a third-party package the way pytest runner does. You could use that to implement the nose2 command.
Still, if it were up to me, I'd try to decouple test running from building, as you're only adding constraints that may later become deprecated as well.

why you can't remove the dependency part while keeping the test runners

Setuptools is aiming to get out of the business of being a swiss-army knife of project management (as distutils was envisioned) and instead focus on providing a best-in-class build implementation (mainly the operations defined by PEP 517). The goal is to separate concerns (SCM tooling, testing, environments, installation, package indexes, distribution, building) into different, largely independent tools, coordinated by standards.

@RonaldAJ Glad you found a workaround. Note that Setuptools also supports defining that command as a plugin, in a third-party package the way pytest runner does. You could use that to implement the nose2 command.
Still, if it were up to me, I'd try to decouple test running from building, as you're only adding constraints that may later become deprecated as well.

why you can't remove the dependency part while keeping the test runners

Setuptools is aiming to get out of the business of being a swiss-army knife of project management (as distutils was envisioned) and instead focus on providing a best-in-class build implementation (mainly the operations defined by PEP 517). The goal is to separate concerns (SCM tooling, testing, environments, installation, package indexes, distribution, building) into different, largely independent tools, coordinated by standards.

@jaraco I guess that good working examples of migration would help. Setuptools is hard to use for people like me who need to make changes very occasionally.

@jaraco I guess that good working examples of migration would help. Setuptools is hard to use for people like me who need to make changes very occasionally.

That would be nice. Unfortunately, because there are such a diverse array of workflows, there's no deterministic migration. However, for the use-case you indicate above, why not simply pip install .; nose2? That should be roughly equivalent to setup.py clean build install nose2. If you need something more elaborate, then consider using a tool like tox or nox or make to facilitate the setup.

That would be nice. Unfortunately, because there are such a diverse array of workflows, there's no deterministic migration. However, for the use-case you indicate above, why not simply pip install .; nose2? That should be roughly equivalent to setup.py clean build install nose2. If you need something more elaborate, then consider using a tool like tox or nox or make to facilitate the setup.

authors: FRidh McSinyx RonaldAJ RonnyPfannschmidt andy-maier graingert jaraco mcepl native-api pganssle techtonik


text:
Increase upload size limit of h2o_pysparkling_x packages

Hello, I'm owner of Sparkling Water https://github.com/h2oai/sparkling-water project which has PySparkling as the Python client. I could't find better place where to ask this then here.
I would like to ask if it would be possible to increase size for our PySparkling package? It reached limit of 60mb ( has now about 61-62 mb). Right now we can't upload releases to pipy.
We have 4 versions of PySParkling package, for each spark:
h2o_pysparkling_2.1
h2o_pysparkling_2.2
h2o_pysparkling_2.3
h2o_pysparkling_2.4
When new major Spark comes out we usually add new one and deprecate and stop updating the last one.
Our release cycle is usually 1 release in 3 weeks for all of those packages. We can also try to remove the old release to clean some space.
Thank you,
Jakub Hava (Kuba)

Could you please confirm the PyPI URL of the project?

https://pypi.org/project/h2o-pysparkling-2.1/
https://pypi.org/project/h2o-pysparkling-2.2/
https://pypi.org/project/h2o-pysparkling-2.3/
https://pypi.org/project/h2o-pysparkling-2.4/
Thank you @jamadden

Hi @jamadden, any update please?
Thanks,
Kuba

The limit for all four projects has been increased to 100MB on pypi.org.

thanks!

Hi @jamadden,
Would it be possible to increase the limit to 15OMB for all four projects? It seems that the packages will grow in the next release.
Thanks,
Marek

Hi @mn-mikke, could you file a new issue? It'll be easier to keep track of each request for increase that way. :)

authors: jakubhava jamadden mn-mikke pradyunsg

repo: pypa/warehouse

license_source: github-api


text:
new Trove classifier request "Framework :: Zope :: 5"

Request to add a new Trove classifier.
The name of the classifier you would like to add

Framework :: Zope :: 5

Why do you want to add this classifier?

The Plone Foundation as Owner and Maintainer of the Zope Projects requests a new Trove Classifier for the next Major Version of The Zope Application Server. Zope 5 is a Major Release as Python 2 Support is stripped out.

Added to both test.pypi.org and PyPI.org

authors: ewdurbin loechel


text:
PEP458: Add minimal RSTUF service configuration

Supersedes: #13943
This PR is part 1 in a series of PRs to integrate Repository Service for TUF (RSTUF) with Warehouse for PEP 458 adoption.
Background
RSTUF maintains a PEP 458 TUF metadata repository as a black box. It provides REST API, which accepts requests upon addition or removal of release files, and a Worker service, which performs the TUF metadata update and signing tasks asynchronously upon API requests.
Change details

Add rstuf-api service to docker-compose.yml

pull pinned image
configure redis

Add rstuf-worker service to docker-compose.yml

pull pinned image
configure storage backend for TUF metadata files
configure Postgres DB for TUF metadata
configure Redis, used as task message queue for communication between API and Worker, and between Workers

Include rstuf db initialization in initdb target in Makefile.

Preview of next PR
The next PR will include:

Signing configuration, to sign online metadata changes
Static root metadata, to bootstrap the RSTUF repository
A Makefile target, to trigger bootstrap
Instructions, to interact with the RSTUF REST API

@lukpueh

i believe we could remove the vault service at this time since nothing integrates with it and it only was added in support of implementing TUF inside warehouse.

I added the vault removal as the first commit to keep a logical sequence in the PR commits.

Thanks @kairoaraujo! Looks great.

Unclear to me why CI is failing. Seems to be unrelated and consistent with other branches.

Unclear to me why CI is failing. Seems to be unrelated and consistent with other branches.

I see this failure in two other opened PRs 🤔

Unclear to me why CI is failing. Seems to be unrelated and consistent with other branches.

I see this failure in two other opened PRs 🤔
https://github.com/pypi/warehouse/actions/runs/7655175103/job/20867003665#step:8:1

I did some investigation and I commented here:
https://github.com/pypi/warehouse/pull/15276#issuecomment-1911775508

source: gharchive/pull-request

authors: ewdurbin kairoaraujo

repo: pypi/warehouse


text:
release gil in core cython/PROJ code

[x] Closes #386
[x] Fully documented, including history.rst for all changes and api/*.rst for new API

@jorisvandenbossche mind trying this out?

@snowman2 Thanks a lot for looking into this!
I think we need to do some timings to check the overhead of releasing the GIL in single threaded cases (releasing/re-acquiring the GIL many times for tiny computations can give quite some overhead).
(I can try to help with that, but that might take a few days)

Looks fine to me:
In [1]: import numpy as np
   ...: from pyproj import Transformer, transform

In [2]: transformer = Transformer.from_proj(2263, 4326)
   ...: x_coords = np.random.randint(80000, 120000)
   ...: y_coords = np.random.randint(200000, 250000)

In [3]: %timeit transform(2263, 4326, x_coords, y_coords)
63.9 ms ± 4.85 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

In [4]: %timeit transformer.transform(x_coords, y_coords)
6.18 µs ± 67.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

@snowman2 I don't think those timings can tell us much (or at least we should compare them with the timing before this PR).
I did some timings on a bigger array, and also looked at how it performs when parallelizing: https://nbviewer.jupyter.org/gist/jorisvandenbossche/a97d780c04959812c40b22d6c866f4fa
So I think the conclusion from that can be that the nogil added in _Proj._fwd does more harm than good.
That said, I was wondering: is there something that those _fwd and _inv methods do differently compared to Transformer? Could they use Transformer under the hood? Because in those methods, we iterate over the coordinates and feed them one by one to proj_trans, while Transformer also handles arrays of coordinates but passes them in one go as array to proj_trans_generic, making this easier to release the GIL.

Interesting! Thanks for taking a look. I just looked at the transformer so it sounds like timing will be needed for the others for verification.

For the transformer it is fine, but for _Proj._fwd, I would remove it (can do a PR if you want). The geodesic one I didn't time.

I will think on it. I think there is probably a way to wrap the whole loop in a nogil with some better reorganization.

See my note above about that. At least conceptually, Proj._inv/fwd seems the same as transform. Does it behave differently is some corner cases?

Could they use Transformer under the hood?

The Transformer can do essentially the same thing.  Re-directing people to use it instead of Proj is my current plan as I don't know everyone's use case to fully test the transition and mostly have Proj for backwards compatibility and don't plan on adding the same functionality. Currently, only has the original functionality.

In that case, I would personally also not do the effort to refactor that for loop to be able to wrap the fool loop in nogil (as such a refactor can then also change corner cases), and simply don't bother with nogil in this function (transform is faster anyway).

Ha, I had the same thought after writing that. If you would like to remove the nogil stuff from Proj, that would be helpful. Thanks!

It was a simple enough fix for Proj, so I added it in #446


text:
Missing example files in libpysal

======================================================================
ERROR: test_fuzzy_contiguity (pysal.lib.libpysal.weights.tests.test_util.Testutil)
Traceback (most recent call last):
File "/home/serge/Dropbox/p/pysal/src/meta/pysal/pysal/lib/libpysal/weights/tests/test_util.py", line 243, in test_fuzzy_contiguity
rs = lps.get_path('map_RS_BR.shp')
File "/home/serge/Dropbox/p/pysal/src/meta/pysal/pysal/lib/examples/init.py", line 35, in get_path
raise KeyError(example_name + ' not found in PySAL built-in examples.')
KeyError: 'map_RS_BR.shp not found in PySAL built-in examples.'

examples live here: https://github.com/pysal/pysal/tree/master/pysal/examples

rio.zip

repo: pysal/pysal


text:
Update & test min reqs + handling upstream deprecation warnings

This PR resolves #162 and resolves #170 along with other warning handling. Two other issues that need to be addressed, but can hold off for later:  #167 & #168.

Can you change the title of the PR so it is clear what it is doing from skimming the commit history?

Done.

Good to merge?

repo: pysal/splot


text:
physical meanings of beta and sigma in smearing SCF

Hello,
I am using smearing SCF as:
beta = 1
mf_ft = addons.smearing(mf, sigma=1./beta, method='fermi', fix_spin=True)
mf_ft.kernel()
What do beta and sigma stand for? And what is the unit of beta?
With my best regards,
Junbo

sigma is the electronic temperature (technically kT) in units of Hartree.
In the example you found, beta is simply being used in its conventional
definition of beta = 1/kT.
On Thu, Dec 19, 2024 at 9:51 AM Jun-Bo Lu @.***> wrote:

Hello,
I am using smearing SCF as:
beta = 1
mf_ft = addons.smearing(mf, sigma=1./beta, method='fermi', fix_spin=True)
mf_ft.kernel()
What do beta and sigma stand for? And what is the unit of beta?
With my best regards,
Junbo
—
Reply to this email directly, view it on GitHub
https://github.com/pyscf/pyscf/issues/2571, or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGAJCZR53OEXZLBPKDGXF32GLMODAVCNFSM6AAAAABT5FDVNOVHI2DSMVQWIX3LMV43ASLTON2WKOZSG42TANJYGI2TAOI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Thank you!
Is there recommended value for beta? I calculate EuCl3 molecule, and its electronic configuration is 4f^6.

Not really, it depends a bit on why you are using smearing. If it's just to
facilitate SCF convergence, then you probably want the smallest sigma
possible that still gives converged SCF.
On Fri, Dec 20, 2024 at 5:32 AM Jun-Bo Lu @.***> wrote:

Thank you!
Is there recommended value for beta? I calculate EuCl3 molecule, and its
electronic configuration is 4f^6.
—
Reply to this email directly, view it on GitHub
https://github.com/pyscf/pyscf/issues/2571#issuecomment-2556720902, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADGAJCZI535OEPQLXB722BD2GPW27AVCNFSM6AAAAABT5FDVNOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJWG4ZDAOJQGI
.
You are receiving this because you commented.Message ID:
@.***>

Please note that if sigma is too small, like 1e-5, you may encounter convergence issues due to numerical noise in the orbital occupancies. To avoid these issues, I recommend sigma not smaller than 1e-3

authors: JunboLu sunqm tberkel

repo: pyscf/pyscf


text:
Advanced example 031-density.py does not output the density in the implied format

Dear sir/madam,
I want to output the electron density of a 3-dimensional electronic state, and Qiming Sun kindly pointed out that advanced example 031 (https://github.com/pyscf/pyscf/blob/master/examples/1-advanced/031-density.py) shows how to do this.
The code indicates that the output should be a 3-dimensional array of the electron density, but the output is[, of course,] a 1-dimensional output. I have tried to change the array to a 3-dimensional array using numpy.array.reshape(), but that doesn't reshape the coordinates correctly.
Is there some way to reshape the 1-dimensional output be reshaped to a 3-dimensional array correctly? The source code seems to indicate that it isn't a bug.
Thank you for your time.
Kind regards,
Marius Jonsson

What do you mean by 3-dimensional electronic state?
The example computes the ccsd 1-electron density on a uniform grid, with rho[i] corresponding to grids[i].

authors: computative fishjojo


text:
Passing datetime strings breaks requests

Breaking change from 0.8.10 --> 0.8.13
When passing parameters, datetime strings are being URL encoded and causing the following response.
Orders.list_orders(marketplaceids=['A2EUQ1WTGCTBG2'], created_after='2021-03-18T18:55:19.458391+00:00', next_token=None)

<ErrorResponse xmlns="https://mws.amazonservices.com/Orders/2013-09-01">
  <Error>
    <Type>Sender</Type>
    MalformedInput
    <Message>timestamp must follow ISO8601</Message>
  </Error>
  <RequestId>70f81462-3cca-45a8-a8e0-bc84ecde41de</RequestId>
</ErrorResponse>

Hey @samamorgan, I was using the current MWS.py version and getting this same error while trying to list_financial_event_groups(created_after=start_date, created_before=end_date). I had to force using an older MWS version: mws==0.8.9. The error I was getting was exactly the same you reported:
mws.mws.MWSError:
<Error>
  <Type>Sender</Type>
  MalformedInput
  <Message>timestamp must follow ISO8601</Message>
</Error>
<RequestId>0e907162-93ad-477f-a043-d51cb33353d2</RequestId>
</ErrorResponse>

@marceloazambuja The simplest workaround until #260 is merged is to convert your date strings to datetime.

@marceloazambuja The simplest workaround until #260 is merged is to convert your date strings to datetime.

I tried it before moving to the 0.8.9 version.... and even using pure datetime instead of string it didn't work.

I haven't used the Finances API, so I can't comment on any potential differences here. The PR I created should address any date string/datetime issues.

Hello guys,
I tried to use mws lib for orders but got this error, any idea on how to solve it ?
mws.mws.MWSError:

Sender
MalformedInput
timestamp must follow ISO8601

8b89a336-f63d-4bff-9daf-d860eb139a4e

Corrected by #263, released in the repo as 0.8.14. Release to PyPI forthcoming.

authors: GriceTurrble lihanpengde marceloazambuja samamorgan

repo: python-amazon-mws/python-amazon-mws

license: Unlicense


text:
Remove various obsolete _compat helpers

See individual commits.

(missed one format string on the first push; should be good now)

repo: python-attrs/attrs


text:
Percent signs escaping in templatetags

Closes https://github.com/python-babel/django-babel/issues/43
In Django >= 1.9, % signs are escaped to %% during extraction
then replaced by % during the rendering. [1]
Before Django 1.9, only single percent signs were escaped.
The extraction now behaves in the same way.
[1] https://github.com/django/django/commit/b7508896fbe19ec2cdeb81565cd587091b6b68d0

project seems dead

repo: python-babel/django-babel


text:
Assertion error in client.prinipal

On master  0.8.0rc0 downloaded from github on 2/8/2021
Traceback (most recent call last):
File "", line 1, in
File "/home/pi/MessageBoard/dev/caldav/davclient.py", line 319, in principal
return Principal(self)
File "/home/pi/MessageBoard/dev/caldav/objects.py", line 398, in init
cup = self.get_properties([dav.CurrentUserPrincipal()])
File "/home/pi/MessageBoard/dev/caldav/objects.py", line 221, in get_properties
properties = self.handle_xml_response(response, props)
File "/home/pi/MessageBoard/dev/caldav/objects.py", line 192, in handle_xml_response
results = response.expand_simple_props(props=props, multi_value_props=multi_value_props)
File "/home/pi/MessageBoard/dev/caldav/davclient.py", line 241, in expand_simple_props
self.find_objects_and_props()
File "/home/pi/MessageBoard/dev/caldav/davclient.py", line 177, in find_objects_and_props
error.assert(not href in self.objects)
File "/home/pi/MessageBoard/dev/caldav/lib/error.py", line 23, in assert
assert(condition)
AssertionError
Note.  Commented out the assertion on line 177 and everything seemed to work fine.
Log files attached.
example1.log

The reply from the server contains two hrefs (one directly in the response block, the other nested inside the propstat/prop blocks), that's probably what's triggering the assert.  I've seen similar things from iCloud.  I have no clue if this is a breach of the standard or not, but I'll make some unit test and make sure that this XML does not cause any asserts to be triggered.
PS: in the current master branch, it's possible to set an environment variable PYTHON_CALDAV_DEBUG_MODE.  If it's set to DEBUG_PDB, one will be thrown into the debugger when asserts are raised.  If set to PRODUCTION, the asserts will log errors rather than break everything.

Oh, when doing more research on it, I can see that the URL is actually repeated three times in the returned XML.  The response block is actually duplicated.  Anyway ... as long as there exists caldav servers giving such a response, we should not throw an AssertionError.  I've remade the code into accepting duplicates.

authors: frank-pet tobixen

repo: python-caldav/caldav


text:
cross-compilation using windows-x64: OverflowError: strings are too large to concat

SRC=~/Projects/python-cmake-buildsystem

docker run -ti -v $SRC:/usr/pysrc:ro thewtex/cross-compiler-windows-x64 bash -c '\
cp /usr/pysrc/Python-2.7.11.tgz /usr/; \
cd /usr; tar -xzvf Python-2.7.11.tgz; \
cd Python-2.7.11; \
patch -p0 -i /usr/pysrc/cmake/patches-win32/01-dynload_win.patch; \
patch -p0 -i /usr/pysrc/cmake/patches-win32/02-signalmodule.patch; \
patch -p0 -i /usr/pysrc/cmake/patches-win32/03-mingw32.patch; \
mkdir /usr/build; cd /usr/build; \
cmake -DCMAKE_TOOLCHAIN_FILE=$CMAKE_TOOLCHAIN_FILE ../pysrc; \
make -j4; \
ctest -R test_abc -V; \
bash'

test 1
    Start 1: test_abc

1: Test command: /usr/bin/wine "/usr/build/bin/python.exe" "-Wd" "-3" "-E" "-tt" "/usr/build/Lib/test/regrtest.py" "-l" "-v" "test_abc"
1: Test timeout computed to be: 1500
1: OverflowError: strings are too large to concat

Cc: @thewtex

Same error happen, building as shared library using:
docker run -ti -v $SRC:/usr/pysrc:ro thewtex/cross-compiler-windows-x64 bash -c '\
cp /usr/pysrc/Python-2.7.11.tgz /usr/; \
cd /usr; tar -xzvf Python-2.7.11.tgz; \
cd Python-2.7.11; \
patch -p0 -i /usr/pysrc/cmake/patches-win32/01-dynload_win.patch; \
patch -p0 -i /usr/pysrc/cmake/patches-win32/02-signalmodule.patch; \
patch -p0 -i /usr/pysrc/cmake/patches-win32/03-mingw32.patch; \
patch -p0 -i /usr/pysrc/cmake/patches-win32/04-uninitialised-flags.patch; \
mkdir /usr/build; cd /usr/build; \
cmake -DBUILD_STATIC=0 -DBUILD_SHARED=1 -DENABLE_CTYPES=0 -DENABLE_SOCKET=0 -DCMAKE_TOOLCHAIN_FILE=$CMAKE_TOOLCHAIN_FILE ../pysrc; \
make -j4; \
ctest -R test_abc -V; \
bash'


text:
Sort the available help channels in #how-to-get-help by position

Currently the dynamic message in #how-to-get-help doesn't sort the available help channels, so this PR sorts the channel by position.

Tested, it works well.

authors: ToxicKidz Xithrius

repo: python-discord/bot

license: MIT


text:
Create CP Notifier Script

The Competitive Programming Notifier Script is a Python tool that alerts users about upcoming coding competitions from selected websites. It offers three notification methods:
Desktop Notifications: Instant alerts on your computer. Email Notifications: Detailed emails with competition info. SMS Notifications: Alerts sent directly to your mobile phone. Key Features:

Configurable Settings: Easily enable or disable notification methods and set up your email and SMS configurations.
Competition Monitoring: Fetches upcoming competitions, which can be customized based on user preferences.
Regular Checks: Runs continuously to ensure timely updates.

This script is perfect for competitive programmers and coding enthusiasts, helping them stay informed and manage their schedules effectively.
Pull Request Template
script name -
Brief about script
Issue no.(must) -
Self Check(Tick After Making pull Request)

[ ] This issue was assigned to me.
[x] One Change in one Pull Request
[ ] My file is in proper folder (Name of folder should be in lowercase with no space in between) (E.g. meet_schedular)
[ ] I am following clean code and Documentation and my code is well linted with flake8.
[ ] I have added README.md and requirements.txt (Include version numbers too e.g. pandas==0.0.1) with my script
[ ] I have used REPO README TEAMPLATE (Necessary)
[ ] Just including required dependencies in requirements.txt (Don't include Python version too)

If issue was not assigned to you Please don't make a PR. It will marked as invalid.

@pawangeek , I've uploaded my PR

repo: python-geeks/Automation-scripts


text:
Embed .xlsx file into .docx

I have a request to embed a .xlsx file into a .docx file. Looking through the docs I am not seeing any immediate information.
Is this type of operation possible? Are there some lower-level methods I could consider using to achieve this type of action?

Not a lot I'm afraid, but there are enough for the enterprising developer I expect :)
The python-pptx project embeds an xlsx file as part of it's chart capabilities, so you could have a look there for some working code. These spots would be a good place to start:

https://github.com/scanny/python-pptx/blob/master/pptx/parts/embeddedpackage.py
https://github.com/scanny/python-pptx/blob/master/pptx/parts/chart.py#L53
https://github.com/scanny/python-pptx/blob/master/pptx/chart/xlsx.py
https://github.com/scanny/python-pptx/blob/master/pptx/chart/data.py#L69

Then you'd need to understand what the XML looks like where the Excel file is actually embedded. opc-diag is handy for that.
Then you'd need to use low-level oxml and lxml calls like OxmlElement() and _Element.append(), etc. to form the right XML in the document XML (document.xml in the .docx package).
You'll need to decide whether to fork and create your own python-docx that includes new part objects and so on, or whether you write "extension" functions (or objects) that you maintain in your own code base, to do the needful as far as adding the Excel-related bits. The latter is generally more flexible as you can  upgrade to new python-docx releases without breaking your code. The former is probably the way if you were going to go for a commit in the main code base, although most folks find it challenging to raise their game to the engineering standard it requires (much of that being the test-driven regimen).

authors: clayk scanny

repo: python-openxml/python-docx


text:
Wrong entrypoint in setup.py

(venv37) jreese@jreese-mbp ~/scratch/aiosqlite-0.10.0 » honesty --help
Traceback (most recent call last):
  File "/Users/jreese/scratch/venv37/bin/honesty", line 5, in <module>
    from honesty.cmdline import main
ImportError: cannot import name 'main' from 'honesty.cmdline' (/Users/jreese/scratch/venv37/lib/python3.7/site-packages/honesty/cmdline.py)

fixed in 821b52

authors: jreese thatch

repo: python-packaging/honesty


text:
Submenus not working

Hello,
I have enabled the "Enable submenu in Custom Nodes" option

But when I am trying to select LoRAs/Checkpoints, it is still in a plain list：

Am I missing anything to config?

Would you be able to run the following command in your browsers console, and let me know the output:
console.log(navigator.platform || navigator.userAgent, (navigator.platform || navigator.userAgent).includes("Win") ? "\\" : "/")
My guess is that it isnt choosing the correct path separator to split by

Ah, I think yes. It is showing as Win32 \, while in the listed menu, the seperator is actually / as in POSIX. May be a Regex or an explicit path resolving js lib can handle it better?

Would you please be able to share the output of the command so I can see what OS/user agent it says you are using

Sure, it is 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 Edg/118.0.0.0'
(The original output is exactly Edg instead of edge)

Thank you!

I've pushed an update for this, hopefully resolves it for you!

authors: clyce pythongosssss

repo: pythongosssss/ComfyUI-Custom-Scripts


text:
🛑 Thumbnail's Api is down

In 15fd7a8, Thumbnail's Api (https://thumbnails.roblox.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Thumbnail's Api is back up in ad1e918.

repo: pythoniaweb/roblox-status


text:
🛑 Node 2 is down

In cf6032b, Node 2 (http://nodeb.boomhost.ml/index.html) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Node 2 is back up in 5b26872.

repo: pythoniaweb/statusboom


text:
Create minglin.py

numbers = [10,29,30,42]
for index,item in enumerate(numbers):
print "(%s,%s)" %(index,item),

use the function enumerate() to get the index and value then use ‘for’ to print the index and value

repo: pythonzhichan/DailyQuestion


text:
Optimize Int8 Woq for CPU

This PR is to optimize Int8 Woq both in gpt-fast and mixtral-moe.
At the current stage, we use torch.ops.aten._weight_int8pack_mm as an workaround. And this workaround will be removed when https://github.com/pytorch/pytorch/pull/120985 is merged in PyTorch stable release. Meanwhile, update int8 weight dimension according to torch.ops.aten._weight_int8pack_mm in https://github.com/pytorch/pytorch/pull/118056 and add CPU profiling.

@HDCharles could you please take a look? Thanks!

Hi @yanboliang , could you please take a look? Thanks!

repo: pytorch-labs/gpt-fast