text:
pipenv.patched.pip._internal.exceptions.InstallationSubprocessError

Pipfile:
`[[source]]
url = "https://pypi.tuna.tsinghua.edu.cn/simple/"
verify_ssl = true
name = "pypi"
[packages]
redis-py-cluster = ""
amap-distance-matrix = ""
typing-environs = ""
sonyflake-py = ""
mongoengine = ""
nest-asyncio = ""
loguru = ""
fastapi = ""
ray = {extras = ["serve"], version = ""}
ortools = ""
pyconcorde = {editable = true,git = "https://github.com/jvkersch/pyconcorde"}
matplotlib = "*"
[dev-packages]
click = ""
pytest = ""
coverage = ""
black = ""
htmlreport = ""
toml = ""
sphinx = ""
sphinx-rtd-theme = ""
sphinx-autobuild = ""
sphinxcontrib-apidoc = ""
sphinxcontrib-napoleon = ""
m2r2 = ""
[requires]
python_version = "3.9"
`
infomation:
Locking [dev-packages] dependencies...
Building requirements...
Resolving dependencies...
✘
✘ Locking Failed!
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 854, in
main()
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 840, in main
_main(
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 820, in _main
resolve_packages(
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 769, in resolve_packages
results, resolver = resolve(
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 749, in resolve
return resolve_deps(
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 1089, in resolve_deps
results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 883, in actually_resolve_deps
resolver.resolve()
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 686, in resolve
results = resolver.resolve(self.constraints, check_supported_wheels=False)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/resolution/resolvelib/resolver.py", line 92, in resolve
result = self._result = resolver.resolve(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/resolvelib/resolvers.py", line 481, in resolve
state = resolution.resolve(requirements, max_rounds=max_rounds)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/resolvelib/resolvers.py", line 348, in resolve
self._add_to_criteria(self.state.criteria, r, parent=None)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/resolvelib/resolvers.py", line 172, in _add_to_criteria
if not criterion.candidates:
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/resolvelib/structs.py", line 151, in bool
return bool(self._sequence)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/resolution/resolvelib/found_candidates.py", line 155, in bool
return any(self)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/resolution/resolvelib/found_candidates.py", line 143, in
return (c for c in iterator if id(c) not in self._incompatible_ids)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/resolution/resolvelib/found_candidates.py", line 44, in _iter_built
for version, func in infos:
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/resolution/resolvelib/factory.py", line 279, in iter_index_candidate_infos
result = self._finder.find_best_candidate(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/index/package_finder.py", line 901, in find_best_candidate
candidates = self.find_all_candidates(project_name)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/index/package_finder.py", line 842, in find_all_candidates
page_candidates = list(page_candidates_it)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/index/sources.py", line 134, in page_candidates
yield from self._candidates_from_page(self._link)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/index/package_finder.py", line 802, in process_project_url
index_response = self._link_collector.fetch_response(project_url)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/index/collector.py", line 577, in fetch_response
return _get_index_content(location, session=self.session)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/index/collector.py", line 480, in _get_index_content
resp = _get_simple_response(url, session=session)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/index/collector.py", line 138, in _get_simple_response
resp = session.get(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/requests/sessions.py", line 600, in get
return self.request("GET", url, **kwargs)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/network/session.py", line 518, in request
return super().request(method, url, *args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/requests/sessions.py", line 587, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/requests/sessions.py", line 701, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/cachecontrol/adapter.py", line 57, in send
resp = super(CacheControlAdapter, self).send(request, **kw)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/requests/adapters.py", line 489, in send
resp = conn.urlopen(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/urllib3/connectionpool.py", line 703, in urlopen
httplib_response = self._make_request(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/urllib3/connectionpool.py", line 449, in _make_request
six.raise_from(e, None)
File "", line 3, in raise_from
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_vendor/urllib3/connectionpool.py", line 444, in _make_request
httplib_response = conn.getresponse()
File "/usr/local/lib/python3.9/http/client.py", line 1377, in getresponse
response.begin()
File "/usr/local/lib/python3.9/http/client.py", line 320, in begin
version, status, reason = self._read_status()
File "/usr/local/lib/python3.9/http/client.py", line 281, in _read_status
line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
File "/usr/local/lib/python3.9/socket.py", line 704, in readinto
return self._sock.recv_into(b)
File "/usr/local/lib/python3.9/ssl.py", line 1242, in recv_into
return self.read(nbytes, buffer)
File "/usr/local/lib/python3.9/ssl.py", line 1100, in read
return self._sslobj.read(len, buffer)
KeyboardInterrupt
^C
root@1ca72d4191f6:/workspaces/quantum-vrp# ^C
root@1ca72d4191f6:/workspaces/quantum-vrp# pipenv install
Pipfile.lock (0e487d) out of date, updating to (c86446)...
Locking [dev-packages] dependencies...
Building requirements...
Resolving dependencies...
✔ Success!
Locking [packages] dependencies...
Building requirements...
Resolving dependencies...
✘ Locking Failed!
ERROR:pip.subprocessor:[present-rich] git clone --filter=blob:none https://github.com/jvkersch/pyconcorde /tmp/pipenv-7c9b568c-src/pyconcorde exited with 128
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 854, in
main()
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 840, in main
_main(
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 820, in _main
resolve_packages(
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 769, in resolve_packages
results, resolver = resolve(
File "/usr/local/lib/python3.9/site-packages/pipenv/resolver.py", line 749, in resolve
return resolve_deps(
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 1089, in resolve_deps
results, hashes, markers_lookup, resolver, skipped = actually_resolve_deps(
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 880, in actually_resolve_deps
resolver = Resolver.create(
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 433, in create
constraints, skipped, index_lookup, markers_lookup = cls.get_metadata(
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 234, in get_metadata
constraint_update, lockfile_update = cls.get_deps_from_req(
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/resolver.py", line 314, in get_deps_from_req
req_list, lockfile = get_vcs_deps(reqs=[req])
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/dependencies.py", line 103, in get_vcs_deps
with temp_path(), locked_repository(requirement) as repo:
File "/usr/local/lib/python3.9/contextlib.py", line 119, in enter
return next(self.gen)
File "/usr/local/lib/python3.9/site-packages/pipenv/utils/dependencies.py", line 315, in locked_repository
with requirement.req.locked_vcs_repo(src_dir=src_dir) as repo:
File "/usr/local/lib/python3.9/contextlib.py", line 119, in enter
return next(self.gen)
File "/usr/local/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/requirements.py", line 2193, in locked_vcs_repo
vcsrepo = self.get_vcs_repo(src_dir=src_dir)
File "/usr/local/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/requirements.py", line 2152, in get_vcs_repo
vcsrepo.obtain()
File "/usr/local/lib/python3.9/site-packages/pipenv/vendor/requirementslib/models/vcs.py", line 79, in obtain
self.repo_backend.obtain(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/vcs/versioncontrol.py", line 521, in obtain
self.fetch_new(dest, url, rev_options, verbosity=verbosity)
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/vcs/git.py", line 276, in fetch_new
self.run_command(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/vcs/versioncontrol.py", line 650, in run_command
return call_subprocess(
File "/usr/local/lib/python3.9/site-packages/pipenv/patched/pip/_internal/utils/subprocess.py", line 224, in call_subprocess
raise error
pipenv.patched.pip._internal.exceptions.InstallationSubprocessError: git clone --filter=blob:none https://github.com/jvkersch/pyconcorde /tmp/pipenv-7c9b568c-src/pyconcorde exited with 128

i also use：
pipenv install -v -e git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde
but not install success
infomation：

@Euraxluo It worked fine in ubuntu linux for me, on windows I get an error indicating an issue with the setup.py for Widnows.  I suspect you are having issue building that package with the setup.py somehow.
$ pipenv install -v -e git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde
Using python: None
Path to python: None
Creating a virtualenv for this project...
Pipfile: C:\Users\matte\Projects\pipenv-triage\issue-5224\Pipfile
Using default python from C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.1520.0_x64__qbz5n2kfra8p0\python.exe (3.10.5) to create virtualenv...
[    ] Creating virtual environment...created virtual environment CPython3.10.5.final.0-64 in 2858ms
  creator CPython3Windows(dest=C:\c\users\matte\.virtualenvs\issue-5224-CCjK2qyB, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=C:\Users\matte\AppData\Local\pypa\virtualenv)
    added seed packages: pip==22.2.1, setuptools==63.2.0, wheel==0.37.1
  activators BashActivator,BatchActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

Successfully created virtual environment!
Virtualenv location: \c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB
Creating a Pipfile for this project...
Installing -e git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde...
Installing package: -e git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde
Writing supplied requirement line to temporary file: '-e git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde'
Installing 'pyconcorde'
$ '\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\Scripts\python.exe' -m pip install --verbose --upgrade --exists-action=i -r 'c:\users\matte\appdata\local\temp\pipenv-8hflv5mw-requirements\pipenv-rkpthj99-req
uirement.txt' -i https://pypi.org/simple
Using source directory: '\\c\\Users\\matte\\.virtualenvs\\issue-5224-CCjK2qyB\\src'
Error:  An error occurred while installing -e git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde!
Error text: Using pip 22.2.1 from C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\lib\site-packages\pip (python 3.10)
Obtaining pyconcorde from git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde (from -r c:\users\matte\appdata\local\temp\pipenv-8hflv5mw-requirements\pipenv-rkpthj99-requirement.txt (line 1))
  Cloning https://github.com/jvkersch/pyconcorde to c:\c\users\matte\.virtualenvs\issue-5224-ccjk2qyb\src\pyconcorde
  Resolved https://github.com/jvkersch/pyconcorde to commit 1b1c3b2d739befcce43cd3c47a217d7e82b928d4
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Checking if build backend supports build_editable: started
  Checking if build backend supports build_editable: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
  Installing backend dependencies: started
  Installing backend dependencies: finished with status 'done'
  Preparing metadata (pyproject.toml): started
  Preparing metadata (pyproject.toml): finished with status 'done'
Collecting numpy>=1.10.0
  Using cached numpy-1.23.1-cp310-cp310-win_amd64.whl (14.6 MB)
Collecting cython>=0.22.0
  Using cached Cython-0.29.32-py2.py3-none-any.whl (986 kB)
Installing collected packages: numpy, cython, pyconcorde
  Running setup.py develop for pyconcorde

  Running command git version
  git version 2.37.1.windows.1
  Running command git clone --filter=blob:none --quiet https://github.com/jvkersch/pyconcorde 'C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\src\pyconcorde'
  Running command git rev-parse HEAD
  1b1c3b2d739befcce43cd3c47a217d7e82b928d4
  Running command pip subprocess to install build dependencies
  Collecting setuptools
    Downloading setuptools-63.4.1-py3-none-any.whl (1.2 MB)
       ---------------------------------------- 1.2/1.2 MB 5.6 MB/s eta 0:00:00
  Collecting numpy
    Using cached numpy-1.23.1-cp310-cp310-win_amd64.whl (14.6 MB)
  Collecting Cython
    Downloading Cython-0.29.32-py2.py3-none-any.whl (986 kB)
       ------------------------------------- 986.3/986.3 kB 15.5 MB/s eta 0:00:00
  Installing collected packages: setuptools, numpy, Cython
  Successfully installed Cython-0.29.32 numpy-1.23.1 setuptools-63.4.1
  WARNING: Missing build requirements in pyproject.toml for pyconcorde from git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde (from -r c:\users\matte\appdata\local\temp\pipenv-8hflv5mw-requirements\pipe
nv-rkpthj99-requirement.txt (line 1)).
  WARNING: The project does not specify a build backend, and pip cannot fall back to setuptools without 'wheel'.
  Running command Checking if build backend supports build_editable
  Running command Getting requirements to build wheel
  C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\Cython\Compiler\Main.py:369: FutureWarning: Cython directive 'language_level' not set, using 2 for now (Py2). This will chang
e in a later release! File: C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\src\pyconcorde\concorde\_concorde.pyx
    tree = Parsing.p_module(s, pxd, full_module_name)
  Compiling concorde/_concorde.pyx because it changed.
  [1/1] Cythonizing concorde/_concorde.pyx
  running egg_info
  creating pyconcorde.egg-info
  writing pyconcorde.egg-info\PKG-INFO
  writing dependency_links to pyconcorde.egg-info\dependency_links.txt
  writing requirements to pyconcorde.egg-info\requires.txt
  writing top-level names to pyconcorde.egg-info\top_level.txt
  writing manifest file 'pyconcorde.egg-info\SOURCES.txt'
  reading manifest file 'pyconcorde.egg-info\SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  adding license file 'COPYING'
  writing manifest file 'pyconcorde.egg-info\SOURCES.txt'
  Running command pip subprocess to install backend dependencies
  Collecting wheel
    Using cached wheel-0.37.1-py2.py3-none-any.whl (35 kB)
  Installing collected packages: wheel
  Successfully installed wheel-0.37.1
  Running command Preparing metadata (pyproject.toml)
  running dist_info
  creating C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info
  writing C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info\PKG-INFO
  writing dependency_links to C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info\dependency_links.txt
  writing requirements to C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info\requires.txt
  writing top-level names to C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info\top_level.txt
  writing manifest file 'C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info\SOURCES.txt'
  reading manifest file 'C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info\SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  adding license file 'COPYING'
  writing manifest file 'C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde.egg-info\SOURCES.txt'
  creating 'C:\Users\matte\AppData\Local\Temp\pip-modern-metadata-gy2td9no\pyconcorde-0.1.0.dist-info'
  adding license file "COPYING" (matched pattern "COPYING*")
    Running command python setup.py develop
    running develop
    C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\command\easy_install.py:144: EasyInstallDeprecationWarning: easy_install command is deprecated. Use build and pi
p and other standards-based tools.
      warnings.warn(
    C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\command\install.py:34: SetuptoolsDeprecationWarning: setup.py install is deprecated. Use build and pip and other
 standards-based tools.
      warnings.warn(
    running egg_info
    writing pyconcorde.egg-info\PKG-INFO
    writing dependency_links to pyconcorde.egg-info\dependency_links.txt
    writing requirements to pyconcorde.egg-info\requires.txt
    writing top-level names to pyconcorde.egg-info\top_level.txt
    reading manifest file 'pyconcorde.egg-info\SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    adding license file 'COPYING'
    writing manifest file 'pyconcorde.egg-info\SOURCES.txt'
    running build_ext
    Traceback (most recent call last):
      File "<string>", line 2, in <module>
      File "<pip-setuptools-caller>", line 34, in <module>
      File "C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\src\pyconcorde\setup.py", line 146, in <module>
        setup(
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\__init__.py", line 87, in setup
        return distutils.core.setup(**attrs)
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\_distutils\core.py", line 185, in setup
        return run_commands(dist)
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\_distutils\core.py", line 201, in run_commands
        dist.run_commands()
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\_distutils\dist.py", line 973, in run_commands
        self.run_command(cmd)
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\dist.py", line 1217, in run_command
        super().run_command(command)
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\_distutils\dist.py", line 992, in run_command
        cmd_obj.run()
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\command\develop.py", line 34, in run
        self.install_for_development()
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\command\develop.py", line 114, in install_for_development
        self.run_command('build_ext')
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\_distutils\cmd.py", line 319, in run_command
        self.distribution.run_command(command)
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\dist.py", line 1217, in run_command
        super().run_command(command)
      File "C:\Users\matte\AppData\Local\Temp\pip-build-env-bbrii3mk\overlay\Lib\site-packages\setuptools\_distutils\dist.py", line 992, in run_command
        cmd_obj.run()
      File "C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\src\pyconcorde\setup.py", line 119, in run
        download_concorde_qsopt()
      File "C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\src\pyconcorde\setup.py", line 76, in download_concorde_qsopt
        qsopt_a_url, qsopt_h_url = QSOPT_LOCATION[platform.system()][machine]
    KeyError: 'Windows'
    qsopt is missing, downloading
    error: subprocess-exited-with-error

    × python setup.py develop did not run successfully.
    │ exit code: 1
    ╰─> See above for output.

    note: This error originates from a subprocess, and is likely not a problem with pip.
    full command: 'C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\Scripts\python.exe' -c '
    exec(compile('"'"''"'"''"'"'
    # This is <pip-setuptools-caller> -- a caller that pip uses to run setup.py
    #
    # - It imports setuptools before invoking setup.py, to enable projects that directly
    #   import from `distutils.core` to work with newer packaging standards.
    # - It provides a clear error message when setuptools is not installed.
    # - It sets `sys.argv[0]` to the underlying `setup.py`, when invoking `setup.py` so
    #   setuptools doesn'"'"'t think the script is `-c`. This avoids the following warning:
    #     manifest_maker: standard file '"'"'-c'"'"' not found".
    # - It generates a shim setup.py, for handling setup.cfg-only projects.
    import os, sys, tokenize

    try:
        import setuptools
    except ImportError as error:
        print(
            "ERROR: Can not execute `setup.py` since setuptools is not available in "
            "the build environment.",
            file=sys.stderr,
        )
        sys.exit(1)

    __file__ = %r
    sys.argv[0] = __file__

    if os.path.exists(__file__):
        filename = __file__
        with tokenize.open(__file__) as f:
            setup_py_code = f.read()
    else:
        filename = "<auto-generated setuptools caller>"
        setup_py_code = "from setuptools import setup; setup()"

    exec(compile(setup_py_code, filename, "exec"))
    '"'"''"'"''"'"' % ('"'"'C:\\c\\Users\\matte\\.virtualenvs\\issue-5224-CCjK2qyB\\src\\pyconcorde\\setup.py'"'"',), "<pip-setuptools-caller>", "exec"))' develop --no-deps
    cwd: C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\src\pyconcorde\
error: subprocess-exited-with-error

× python setup.py develop did not run successfully.
│ exit code: 1
╰─> See above for output.

note: This error originates from a subprocess, and is likely not a problem with pip.

Using pip 22.2.1 from C:\c\Users\matte\.virtualenvs\issue-5224-CCjK2qyB\lib\site-packages\pip (python 3.10)
Obtaining pyconcorde from git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde
  Cloning https://github.com/jvkersch/pyconcorde to c:\c\users\matte\.virtualenvs\issue-5224-ccjk2qyb\src\pyconcorde
  Resolved https://github.com/jvkersch/pyconcorde to commit 1b1c3b2d739befcce43cd3c47a217d7e82b928d4
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Checking if build backend supports build_editable: started
  Checking if build backend supports build_editable: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
  Installing backend dependencies: started
  Installing backend dependencies: finished with status 'done'
  Preparing metadata (pyproject.toml): started
  Preparing metadata (pyproject.toml): finished with status 'done'
Collecting numpy>=1.10.0
  Using cached numpy-1.23.1-cp310-cp310-win_amd64.whl (14.6 MB)
Collecting cython>=0.22.0
  Using cached Cython-0.29.32-py2.py3-none-any.whl (986 kB)
Installing collected packages: numpy, cython, pyconcorde
  Running setup.py develop for pyconcorde

Installation Failed

i work in devcontainer，image: python:3.9
i can work in pipenv shell，look like good。
not raise
Locking [packages] dependencies... Building requirements... Resolving dependencies... ERROR:pip.subprocessor:[present-rich] git clone --filter=blob:none https://github.com/jvkersch/pyconcorde /tmp/pipenv-46e050sg-src/pyconcorde exited with 128 Traceback (most recent call last)
infomation
root@1ca72d4191f6:/workspaces/quantum-vrp# pipenv shell
Launching subshell in virtual environment...
root@1ca72d4191f6:/workspaces/quantum-vrp#  . /workspaces/quantum-vrp/.venv/bin/activate
(quantum-vrp) root@1ca72d4191f6:/workspaces/quantum-vrp# pip install -v -e git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde
Using pip 22.2.2 from /workspaces/quantum-vrp/.venv/lib/python3.9/site-packages/pip (python 3.9)
Obtaining pyconcorde from git+https://github.com/jvkersch/pyconcorde#egg=pyconcorde
Running command git config --get-regexp 'remote..*.url'
remote.origin.url https://github.com/jvkersch/pyconcorde
Updating ./.venv/src/pyconcorde clone
Running command git version
git version 2.30.2
Running command git fetch -q --tags
Running command git show-ref HEAD
1b1c3b2d739befcce43cd3c47a217d7e82b928d4 refs/remotes/origin/HEAD
Running command git reset --hard -q 1b1c3b2d739befcce43cd3c47a217d7e82b928d4
Running command pip subprocess to install build dependencies
Collecting setuptools
Downloading setuptools-63.4.1-py3-none-any.whl (1.2 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.2/1.2 MB 20.0 kB/s eta 0:00:00
Collecting numpy
Downloading numpy-1.23.1-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (17.1 MB)

Maybe this is a problem that runs git in the process

@Euraxluo Does your dev container have git installed?

yes，pipenv shell Run in the same development container

@Euraxluo do you have a Dockerfile that shows the issue happening with image: python:3.9?  Also, pipenv=2022.8.15 was just released, you might check again.

ok
i will try

authors: Euraxluo matteius


text:
setuptools_scm tries to create archive of outer git repository

When setuptools_scm is used and packed python module comes not from git repository, but from usual archive, and build is happening inside other (outer) git repository, file_finder_git.py tries to create git archive of outer repository.
This happens with latest setuptools_scm.

The following workaround seems to work for us https://github.com/OpenIndiana/oi-userland/pull/5194 . But it's not the real fix, as we just check that top-level repository is not setup.py-based.

@pawamoy thanks for the reference, i wonder if a managed global to inform the hook of the correct expected toplevel would sort this out nicely

Looking for setup.py (or pyproject.toml) to find the root is not sufficient, because there might be symlinks to somewhere else above setup.py but still in the same source repo.
That said I think a setup.py designed to work with the scm file finder cannot work with a source archive? It should work with a sdist though, I don't remember exactly the details right now.

bythat i meant that in the setup call/integration we set the expected scm root based on the input data and use it to ensure the file finder does not step out of the overall file tree
this will basically be a tactical "monkeypatch"

note that the file finder typically work with the sdist, but the git folder finding is missaligned due to the lack of extra information

@pawamoy thanks for the reference, i wonder if a managed global to inform the hook of the correct expected toplevel would sort this out nicely

Isn't this what root option is for? Or is that only used for version detection and not file-finding (not sure how that works exactly yet, though)?

(Off-topic: you're mentioning the wrong user :sweat_smile: @pawamoy instead of @pyhalov I guess)

@matthijskooijman file finders do not have access to that metadata CC @jaraco for the setuptools side

I can take a look, but can you create a reproducer for the issue? Is there a way you could avoid expanding sdists into the git repo to bypass the issue?

probably, but not soon

I still have this issue, and my 'outer' git repo is big, so git archive --prefix /outer/dir HEAD runs and takes a long time.
GIT_CEILING_DIRECTORIES is ineffective because setuptools-scm is explicitly passing in the --prefix.
I am looking for ways to tell setuptools-scm not to look above the project root directory - either by default or by configuration, command line, or environment.  Or at least hints in the right direction.

This affects the file finder
Setuptools is insufficient there
We may need a very crude global registry for configurations and roots to remove thr need for searching

Here's steps for a "simple" test case:
# assuming posix shell for these steps...
# (1) maybe set up a clean virtual environment (python -m venv testenv && . testenv/bin/activate)
# (2) install build, setuptools-scm, wheel
$ pip install build setuptools-scm wheel
$ pip list
# (3) use git to clone some large-ish repo, like the Linux kernel or FreeBSD ports tree
$ git clone --depth=1 --no-checkout https://git.freebsd.org/ports.git
# (4) cd somewhere in the git repo
$ mkdir ports/somewhere
$ cd ports/somewhere
# (5) build simple project
$ mkdir testproj
$ cd testproj
$ cat > pyproject.toml << "eof"
[project]
name = "foo"
version = "1"
eof
$ time python -m build --no-isolation

While that is running, check the process list and observe that one or more git archive processes spin up that add time to the build.  --no-isolation seems to be important in this test case - without it, the build is quicker.

source: gharchive/issue

authors: RonnyPfannschmidt jaraco jhgit matthijskooijman pawamoy pyhalov sbidoul

repo: pypa/setuptools-scm

license: MIT

license_type: permissive

license_source: github-api


text:
Daily and weekly download traffic stats

What's the problem this feature will solve?
I need to calculate money savings from traffic savings in https://github.com/pypa/warehouse/pull/9972 to get understanding of the value of my efforts, to pitch it for better job offers.
Describe the solution you'd like
https://pypi.org/stats/ endpoint provided rendered number of the daily and weekly outgoing traffic served by infrastructure, split by traffic provider.
Ideally there should also be a link to API that allows to query more specific or detailed info.
Additional context
If there a list of all hosting infrastructure used by PyPI for the start?

See https://warehouse.pypa.io/api-reference/bigquery-datasets.html#download-statistics-table

@pradyunsg have you checked that the table includes the downloaded size before closing the issue? Because there is no traffic stats.

I hadn't, and, no, that data is not directly accessible in a single spot.
Your best bet would be to also make a few hundred API requests to the JSON API to know the size of the distribution files which, combined with the total download counts, will give you your answer.

@pradyunsg or reopen the issue to make the data available without few thousands JSON API calls.

piwheels provides the monthly bandwidth stats - https://blog.piwheels.org/piwheels-stats-2021q3/ and I don't see the reason why $300000 project can't do the same. @pradyunsg reopen?

This is a duplicate of #787.

authors: abitrolly di pradyunsg

repo: pypa/warehouse


text:
Add help text for 2FA

As part of the work that @woodruffw is doing on 2FA here, I would like to add the following questions / help text to https://pypi.org/help/
I am posting this text here to receive feedback prior to making a PR:

How do I access my PyPI account using two factor authentication?
Users who have chosen to set up two factor authentication (2FA) on their PyPI account must provide a second method of identity verification (other than their username and password) to log in.
PyPI supports two 2FA methods: Generating a code through a TOTP application, and using a U2F security key.
How do I generate a code through a TOTP application?
When enabling two factor authentication (2FA) via TOTP in your account admin, you were asked to provision an application (usually a mobile phone app) in order to generate authentication codes. Popular applications include:

Google Authenticator for Android or iPhone
1Password
Authy
LastPass Authenticator

Open the application of your choice to generate a code. If you have deleted your application or lost your phone, you can still authenticate using a security key (if you have set up this 2FA method), or bypass 2FA using a recovery code.
How do I login with a U2F key?
A universal second factor (U2F) key is hardware device that communicates via USB, NFC, or Bluetooth. Popular keys include Yubikey, Google Titan and Thetis. PyPI supports any FIDO U2F compatible key.
Users who have set up this second factor will be prompted to use their key (usually by inserting it into a USB port and pressing a button) when logging in.
If you have lost your U2F key, you can still authenticate using a TOTP application (if you have set up this 2FA method), or bypass 2FA using a recovery code.
What is a recovery code?
When setting up two factor authentication on your account, you were provided with the option to add a set of 8 recovery codes, and instructed to keep these in a safe place.
These codes are usually a string of numbers, letters or words that act as a one time password. If you are unable to login to PyPI using your normal second factor, you can use one of these codes to bypass the 2FA process. Once you have used a backup code, you cannot use it again.
It is important that you store these codes securely by either printing or writing down the codes - we strongly recommend that you do not store them in a password manager, or on any device.
If you lose your recovery codes, and cannot authenticate with one of your 2FA methods, you will be locked out of your PyPI account. The PyPI team cannot manually grant you access to your account.

@woodruffw a couple of questions:

is the FIDO link appropriate?  Or should I link to a different page, with different text?
is These codes are usually a string of numbers, letters or words that act as a one time password accurate?  Or would it be better to say "These codes are made up of numbers, letters and symbols"? e.g. I think this text is currently too generic and should be updated based on what our actual recovery codes will look like.

@brainwane I would appreciate your feedback on this, if you have time :)

is the FIDO link appropriate?  Or should I link to a different page, with different text?

No strong opinions but we could link directly to the specifications page: https://fidoalliance.org/specifications/download/

2. is These codes are usually a string of numbers, letters or words that act as a one time password accurate?  Or would it be better to say "These codes are made up of numbers, letters and symbols"? e.g. I think this text is currently too generic and should be updated based on what our actual recovery codes will look like.

My original thought was to make the recovery codes identical in format to TOTP codes (i.e., 6 digits), but that may be a little too simple to discourage brute forcing (even with rate limiting). What do you think about making them hex strings? We could minimize some of the tediousness/eye-strain of typing hex characters with optional dashes, e.g.:
1234-abcd
feed-cafe

If that sounds good to you, we could change the language to "[these codes are] a string of 8 hexadecimal characters, (optionally) separated in the middle by a dash" or similar.

I agree, I don't think 6 digits have enough entropy for recovery codes.
I think ten hex digits separated by a dash would be appropriate -- this is also what Github does:

(Don't worry, these aren't my recovery codes.)

I think ten hex digits separated by a dash would be appropriate -- this is also what Github does

Sounds good! That's what I'll go with.

Thanks for your feedback @woodruffw and @di.
Another question - @woodruffw - you mentioned that creating recovery codes should be optional, which is why the help text says "you were provided with the option to add a set of 8 recovery codes".
Can you explain why we should make this optional?  What is the use case for a user not to want recovery codes?  It seems like playing with :fire: fire :fire: to me.

Sure!
Like you said, recovery codes bypass the two-factor process: an account that has 2FA + recovery codes is strictly less secure than account that has just 2FA. 2FA + recovery codes is still preferable to just a password, but my thought is that any action that decreases the security of an account should require affirmative approval from the user (which is also why the current TOTP removal form requires the user to type their password).
I think we can mitigate some of the hazard of users losing account access by offering them the option to add recovery codes immediately after adding a second factor (along with a warning about playing with :fire: if they don't). Does that sound reasonable?

From a support perspective, requiring recovery codes should cut down on the number of "unrecoverable account" requests we get as administrators.

From a support perspective, requiring recovery codes should cut down on the number of "unrecoverable account" requests we get as administrators.

Yeah, this would unfortunately increase the burden on administrators. There are additional steps that can be taken to minimize that, however: in addition to suggesting recovery codes after the user adds a second factor, we can add a flash to the management page/additional warning text in the two factor section, add it to an email that notifies them of their second factor, etc.
For context:  GitHub, DigitalOcean, and Google allow second factor provisioning without recovery codes, while Dropbox appears to require them. So I can't defend it as a uniform practice :smile:

I'm +1 to @woodruffw's gameplay:

There are additional steps that can be taken to minimize that, however: in addition to suggesting recovery codes after the user adds a second factor, we can add a flash to the management page/additional warning text in the two factor section, add it to an email that notifies them of their second factor, etc.

Another idea...
This is a bit in the weeds, but... Is it possible we could implement a recovery process that doesn't strictly bypass MFA using recovery codes, but where those recovery codes... or even a single code... could be used as a "vouch" when requesting account recovery from admins. That would at least help expedite the process of admin assisted recovery.

Another option, for account recovery: make it possible but with a long delay:

wait 30 (or 60, 90 days) before you grant account recovery
ask at sign-up for phone number to text in case of account recovery request
email/text weekly with links that let you cancel the account recovery request
Notify maintainers on shared projects that someone on their projects has initiated account recovery.  Presumably these people have alternative methods to contact the person who owns the account to get their attention and/or can remove the account from their projects if something seems suspicious.  Also, optionally, permit shared maintainers to take ownership of a shared project during account recovery time if they suspect nefarious activity.
Optionally post notices on projects where a maintainer has requested account recovery during the waiting period and maybe after for a period of time (90 days?).

If recovery request does not get cancelled, assume it's legit and let it go through.
The above process, while being a bit non-standard and potentially embarrassing for someone who loses access to their account, still permits account recovery in a way that mitigates the potential for bad actors to unknowingly get access to a project and upload malicious code (which I assume is the main attack vector to be worried about with account recovery).

ask at sign-up for phone number to text in case of account recovery request
email/text weekly with links that let you cancel the account recovery request

SMS is completely broken as an authenticity channel, so adding texts to the recovery process would probably increase rather than decrease an attacker's chances of gaining access to an account. Email should be fine, with the normal caveats about phishing. But most of this pertains to the general account recovery process, not specifically how we handle 2FA recovery tokens or how we do account recovery when a user has enabled 2FA but lost their second factors :-).

Notify maintainers on shared projects that someone on their projects has initiated account recovery.  Presumably these people have alternative methods to contact the person who owns the account to get their attention and/or can remove the account from their projects if something seems suspicious.  Also, optionally, permit shared maintainers to take ownership of a shared project during account recovery time if they suspect nefarious activity.
Optionally post notices on projects where a maintainer has requested account recovery during the waiting period and maybe after for a period of time (90 days?).

Notifying maintainers on shared projects and posting recovery notices are great ideas, and I think both will follow from the audit log/trail work that Trail of Bits has been contracted to work on.

SMS is completely broken as an authenticity channel, so adding texts to the recovery process would probably increase rather than decrease an attacker's chances of gaining access to an account.

Keep in mind that with my proposal, SMS only allows you to cancel account recovery, it doesn't verify anything.  If an attacker hacked your phone account, they would have to keep it longer than the waiting period so that you wouldn't get the cancel notification by text.  Assuming anyone would notice and rectify that their phone no longer worked in 30? days, then I don't see how using SMS in this fashion is a negative.

Yep, I think I misunderstood! In that scenario, SMS would be just fine.

So, based on what I'm reading here:

we are comfortable with making recovery codes optional
we are prepared to offer users manual account recovery (this will require us to change the proposed help text above, which currently reads "The PyPI team cannot manually grant you access to your account.")
we need to define a manual account recovery process

@di @ewdurbin @woodruffw do you agree with this summary?  If so, let's open a separate issue for discussing manual account recovery, to keep things simple and close off this ticket?  We can move over the comments on this thread.

@nlhkabu that sounds like a great gameplan to me.

@nlhkabu +1 from me.

Closing off this issue, as I have now opened #5758.
The conclusion here is that we will offer manual account recovery. I have updated the suggested help text to be:

The PyPI team can manually grant you access to your account under limited circumstances.

I suggest that once we define the account recovery process in #5758, we add this information as an additional FAQ, linking to it from this sentence.

authors: di ewdurbin nlhkabu rsyring woodruffw


text:
Make QR code for TOTP more specific, informative

What's the problem this feature will solve?
The QR code (for Duo Mobile, at least) produces an entry with just the username, which is ambiguous to the user.
Describe the solution you'd like
More helpful would be, e.g., test.pypi.org-$username to show which PyPI (and really which site) the account is for, AND which account it is.
Additional context
Submitted at the PyCon North America sprints by signop who is probably @signop; thank you for testing!
cc @steiza

@di @woodruffw If this is easy, let's try to get it in before we wrap up the OTF milestone?

Just confirming over here too that #5809 is the same thing I was after with my request. Thanks all!

Hmm, so this is how we're generating the TOTP provisioning URI:
otp.generate_totp_provisioning_uri(
    totp_secret,
    self.request.user.username,
    issuer_name=self.request.registry.settings["site.name"],
)

Which yields a URI like this:
otpauth://totp/Warehouse:foobar?digits=6&secret=TOTP_SECRET_HERE&algorithm=SHA1&issuer=Warehouse&period=30

So, TOTP applications should have enough information to unambiguously identify (Warehouse, username) tuples. For example, this is what I get with Google Authenticator:

Whereas for Duo:

Fixing this is a bit of a double-edged sword: we could change the otpauth username field to something like Warehouse-$username, but that would probably lead to some confusing presentations on TOTP applications that parse the otpauth:// scheme correctly (like Google Authenticator and FreeOTP).

Somewhat related: we can change the issuer name from site.name to warehouse.domain/request.domain to present to the user as "pypi.org" or "test.pypi.org" instead of just "Warehouse". But that doesn't improve things for TOTP applications that don't respect the issuer name/parameter.

@steiza do I recall correctly that there's an update on the Duo Mobile side that partially addresses this issue?

Oops! Sorry, I'm not sure how I missed this back in May.
I haven't worked on the mobile app, but my understanding is that if the URI contains issuer=PyPI (as https://pypi.org currently does), then it will show up in Duo Mobile with:

the PyPI logo
the first line will read "PYPI" (sorry for the capitalization - the first line in the Duo Mobile app is always all uppercase)
the second line will be the username

If the issuer is set to any other value, like TestPyPI (as http://test.pypi.org did when I last tested it), or Warehouse, then the first line will read "THIRD-PARTY" and there won't be a logo.
This isn't ideal, but it shouldn't be confusing to users of pypi.org. I can definitely see how this would be confusing to users of test.pypi.org.

authors: brainwane signop steiza woodruffw


text:
Fixed alignment for author_profile on tablet and smaller devices

Resolves #6372
Screenshot for visual confirmation

Hi @backtrackbaba, are you able to resolve my comment here? https://github.com/pypa/warehouse/issues/6372#issuecomment-724287065

Hey @di, I'm sorry I was not well and away from stuff. I've resolved it and I'll push it in a few hours.
Sorry for the delay

@backtrackbaba No worries! Just wanted to check in, no rush.

Thank you for understanding @di. I've added the commit as discussed in https://github.com/pypa/warehouse/issues/6372#issuecomment-724287065
Here are the screenshots of various sizes
Large Devices (1000 px and 1001 px)

Small Devices (400 px and 401 px)

Thanks @backtrackbaba!

source: gharchive/pull-request

authors: backtrackbaba di


text:
Houdini: Move Houdini Save Current File to beginning of ExtractorOrder

Brief description
In the spirit of this PR https://github.com/pypeclub/OpenPype/pull/2744 with this commit moving the order for the Save Scene plug-ins to beginning of ExtractorOrder this makes Houdini align with that too.
As discussed in the comments this seemed like the more sensible moment to save the current workfile.
Additional note
In Houdini there seemed to be two plug-ins involved with saving - one operating at a different target for different families.
We could technically add both in a single file and do something like:
class SaveCurrentScene(pyblish.api.ContextPlugin):
    """Save current scene"""

    label = "Save current file"
    order = pyblish.api.ExtractorOrder - 0.49
    hosts = ["houdini"]
    targets = ["deadline"]

    def process(self, context):
        ...

# Inherit from SaveCurrentScene to always save for all families for target `deadline`
class SaveCurrentSceneDeadline(SaveCurrentScene):
    hosts = ["houdini"]
    targets = ["deadline"]

That way the logic could be less duplicated and the Save plug-ins close together.

Shouldn't we add more families there, or maybe use it for all of them?

Shouldn't we add more families there, or maybe use it for all of them?

Quickly checked with our Houdini artist - he had no issue with scene being saved on all families by default. We can always tone that down if we notice issues with that approach.

or maybe use it for all of them?

Implemented with https://github.com/pypeclub/OpenPype/pull/2747/commits/7de42ee923dabba0c534774d6367fc44df67ecf6

authors: BigRoy antirotor

repo: pypeclub/OpenPype


text:
feat: add gzip compression

Closing in favor of #55 (this one is a fork PR so I can't edit it)

authors: korniltsev petethepig

repo: pyroscope-io/pyroscope-rs


text:
DistanceBand error (AttributeError: power not found)

Getting an error when attempting to run DistanceBand with binary=False
import pysal as ps
pts = [(10, 10), (20, 10), (40, 10), (15, 20), (30, 20), (30, 30)]

This works fine:
w = ps.DistanceBand(points,threshold=11.2)
However this:
w = ps.DistanceBand(points,threshold=11.2,binary=False))
Yields the following error:
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/Users/.../python2.7/site-packages/pysal/weights/Distance.py", line 789, in __init__
    neighbors, weights = self._distance_to_W(ids)
  File "/Users/.../python2.7/site-packages/pysal/weights/Distance.py", line 888, in _distance_to_W
    weighted = self.dmat.power(self.alpha)
  File "/Users/.../python2.7/site-packages/scipy/sparse/base.py", line 499, in __getattr__
    raise AttributeError(attr + " not found")
AttributeError: power not found

Thank you for any information or suggestions!
(Hope this isn't a duplicate, searched issues and didn't find anything)

Platform information:

('posix', 'darwin')
('Darwin', '14.5.0', 'Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016; root:xnu-2782.50.9~1/RELEASE_X86_64', 'x86_64')

Python version:

2.7.12 (default, Dec 16 2016, 09:10:09)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]

SciPy version:
0.15.1
NumPy version:
1.11.2

Can you post what version of pysal you are running:
pysal.version

Of course I left off the obvious one, 1.13.0

I can't exactly reproduce your error (there are syntax errors in your code), but I've attached an image of what behavior I see:

Can you run that code and report back if you are seeing something different?

Sorry, errors corrected.
Still getting the same AttributeError: power not found

Because that threshold distance results in a disconnected observation (i.e., the island warning), the binary=False option runs into an edge case that we haven't covered. So thanks for the report!
That said, if you bump up the distance threshold, all observations are connected and the binary case behaves as expected:
In [1]: import pysal as ps

In [2]: pts = [(10, 10), (20, 10), (40, 10), (15, 20), (30, 20), (30, 30)]

In [3]: w = ps.DistanceBand(pts, threshold=11.2)
/Users/serge/anaconda3/envs/pysal/lib/python2.7/site-packages/pysal/weights/weights.py:186: UserWarning: There is one disconnected observation (no neighbors)
  warnings.warn("There is one disconnected observation (no neighbors)")
/Users/serge/anaconda3/envs/pysal/lib/python2.7/site-packages/pysal/weights/weights.py:187: UserWarning: Island id: 2
  warnings.warn("Island id: %s" % str(self.islands[0]))

In [4]: w = ps.DistanceBand(pts, threshold=11.2, binary=False)
/Users/serge/anaconda3/envs/pysal/lib/python2.7/site-packages/scipy/sparse/data.py:94: RuntimeWarning: divide by zero encountered in reciprocal
  return self._with_data(data ** n)

In [5]: w = ps.DistanceBand(pts, threshold=14.2, binary=False)

In [6]:

Aha, got it. Thanks for checking it out!

authors: sjsrey tlangland

repo: pysal/pysal


text:
Fix a warning about dash-separated cfg key

/usr/lib/python3.10/site-packages/setuptools/dist.py:723: UserWarning: Usage of dash-separated 'description-file' will not be supported in future versions. Please use the underscore name 'description_file' instead

Thanks for the change! I'll give it a few days in case any of the other maintainers have comments, then I'll merge this.

authors: diazona felixonmars

repo: pytest-dev/pytest-localserver


text:
Updated conda_compile

The protocol of repo.continuum.io changed to HTTPS, so the URL needs to be updated (cf. Support INC0051925).  I also added conda clean -pt --yes > /dev/null steps earlier to minimize the disk footprint.

Looks good. verified locally.

authors: codecheetos john-k-ge

repo: python-analytics/conda-buildpack


text:
avoid log(0) in automatic timevector calculation

The current automatic timevector calculation throws a warning when zero valued poles are present.
(Switch off display of whitespace changes for review)

Coverage increased (+0.007%) to 84.218% when pulling ddef939157bd913b2b48f6aba46f6b7e63042bfd on bnavigator:zero-poles-time-vector into d3142ff24c7af5e2c0843fd16d0e1be82b322bb9 on python-control:master.

Good catch. Hadn’t thought about testing for that before. S
On Thu, Jul 30, 2020 at 6:47 PM Ben Greiner notifications@github.com
wrote:

The current automatic timevector calculation throws a warning when zero
valued poles are present.
(Switch off display of whitespace changes for review)
You can view, comment on, or merge this pull request online at:
https://github.com/python-control/python-control/pull/441
Commit Summary

no log(0) in automatic timevector calculation

File Changes

M control/timeresp.py
https://github.com/python-control/python-control/pull/441/files#diff-e216ba2d66c950242b1475a045e3cd33
(83)

Patch Links:

https://github.com/python-control/python-control/pull/441.patch
https://github.com/python-control/python-control/pull/441.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/python-control/python-control/pull/441, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AN74SSIIXBC4JI66UH6NAVDR6IPADANCNFSM4PPDXKGA
.

--
Sawyer Fuller
Assistant Professor of Mechanical Engineering
Adjunct, Paul G Allen School of Computer Science
University of Washington
http://faculty.washington.edu/~minster/
(Typed with my thumbs)

authors: bnavigator coveralls sawyerbfuller

repo: python-control/python-control

license_source: bigquery


text:
Add Win32Raw printer to available printers

Contributor checklist

[X] I have read the CONTRIBUTING.rst
[X] I have tested my contribution on these devices:

Windows 10 w. simulator

[x] My contribution is ready to be merged as is

Description
Hi there,
I've added a basic implementation of a win32 printer-queue based printing support. I believe that would be nicer than the current libusb juggling.
Right now I've tested it manually using several simulators. I hope to have a real printer soon. :)

Thank you for your contribution and sorry for the long delay. I will try to check your PR as soon as possible.

Hi @ramonpoca,
did you get around to testing it with a real printer?

Yep, in fact we're using it.

OK, great. Thank you for the information!

authors: patkan ramonpoca

repo: python-escpos/python-escpos

license: mit


text:
New Extended Address record type mode saving in 'write_hex_file' function

Hello,
I've finally pushed my changes, which will solve the problem described by me here: #40
There is new parameter 'ext_addr_mode' for 'write_hex_file', which will handle the issue in following way.

ext_addr_mode='linear' (default) - this is old behavior, it will force to use Extended Linear Address records, so it's backward compatible
ext_addr_mode='segment' - this option forces to use Extended Segment Address records, will throw exception, when data is to big to fit 1MB address space or Starting Linear Address is defined
ext_addr_mode='auto'  - this option will automatically detect which mode to use, basing firstly on Starting Address record type, secondarily (when there is no Starting Address record) on final data length, will throw exception like in point 2 (whenever 'segment' mode is negotiated).

I did the implementation in few days, but I had problem to manage UnitTest for this change. I hope everything is OK there.

Hmm, I didn't see that before, but there is a pull-up request (old one though), which is strongly related with this topic: #5
That makes a little different approach. It's more global.
Especially this comment seems to define the implementation:

So, my plan would be like this:

Old name "hex" still be used for automatic decision about using record types if start address present.
Your patch introduces good feature for generating desired format, let's keep it.
Add support for i8hex, i16hex, i32hex into library, as well as to bin2hex convertor.
More tests :-)

Originally posted by @bialix in https://github.com/python-intelhex/intelhe/pull/5#issuecomment-213300462

I could do that if there are no objections. But right now I'm confused :)

OK, my bad. It was 4 years ago. A long time ago in far far galaxy...
IntelHex project was on hold all those years.
Re-reading my comments on that PR I see it was something good about that patch.
Can we take good parts from two?
I need to re-evaluate both patches.

I see no problem in "merging" both solutions. The only thing here is what You consider as common part and what is need to be changed. This can be done in several variants.
How I see this?

I would stay with new options naming: "linear", "segment" and "auto". For me it's confusing to have options like 'i8hex', 'i16hex', 'i32hex' - only last one tells "truth" about address spacing, 'i8hex' has 16-bit address spacing, 'i16hex' - has 20-bit address spacing. But if You insist to use that notation then no problem at all.
I would only change the name of the new option "ext_addr_mode" => "addr_format" (or similar?)
propagate that parameter into "to_file" method and "bin2hex" as well
Which option will do what (I mark [?], where I'm not sure):

no option/default or "auto":

if no Starting Address and last address is <64KB hex is saved with no Extended Record
if no Starting Address and last address is >=64KB Extended Segment Address records will be used
if no Starting Address and last address is >=1MB Extended Linear Address records is used
if Starting Segment Address is present and last address is >=64KB then Extended Segment Address records will be used ; if last address is <64KB, then no Extended Address record is needed
[?] if Starting Segment Address is present and last address is >=1M then Extended Linear Address records will be used and Starting Address will be converted into Linear (not a real life scenario, but since it's 'auto' format there shouldn't be any errors)
if Starting Linear Address is detected and last address is >=64KB then Extended Linear Address record is used; if last address is <64KB, then no Extended Address record is needed

"segment" option:

[?] if no Starting Address and last address is <64KB hex is saved with no Extended Record (technically no problem to add an Extended Record, but in my opinion it should be kept as simple as it can be)
exception should be thrown whenever last address or Starting Address record is >=1MB
Starting Linear Address should be converted into Segment if it is <1MB
in other cases Starting Segment Address  is "passed" and Extended Segment Address records are used (only when last address >64KB)

"linear" option:

[?] if no Starting Address and last address is <64KB hex is saved with no Extended Record (technically no problem to add an Extended Record, but in my opinion it should be kept as simple as it can be)
Starting Segment Address should be converted into linear (even address is <1MB)
in other cases Starting Linear Address  is "passed" and Extended Linear Address records are used (only when last address >64KB)

And I think that is all. Tell me what You think and I'll start to work on this :)

I have a question. Have You check the code in this pull-up request?

Sorry, I haven't. Done now, for core part, except tests.

I've added a new option for 'ext_addr_mode' - 'none'. When selected it only checks if last address fits into 64KB. It's just to have consistent solution for all options ('segment', 'linear').
If You feel that naming for that option is not good, please let me know.

I can't see unit tests for new feature. Can you add some?

I can't see unit tests for new feature. Can you add some?
Test for new 'none' option are there. I didn't do special test suite for it. Just added/changed to which I created before.
If You do simple text search over 'test.py' file using this keyword: 'none', then You will find tests for that feature.

I haven't noticed changes to tests - because it says diff to large. Again line edings. Please fix it.
I would recommend to make a fresh start, or squash commits together after fixing line endings.

You mean to squash all the commits in this pull request? Is this even possible after everything is pushed on repo?

I think you will need to use git push --force or something like that.

I left 'X' in 'NEWS' on purpose, as I can't predict the future ;)

@bialix I don't know if You get the notifications I had corrected everything that you requested. It's waiting for You review :)

Sorry for delay! I can't review it right now. I'll try my best soon.

repo: python-intelhex/intelhex


text:
Automerging tables

Hello,
when adding two tables into a document object, like following:

doc = docx.Document()
records = (
    (3, '101', 'Spam'),
    (7, '422', 'Eggs'),
    (4, '631', 'Spam, spam, eggs, and spam')
)
section = doc.sections[-1]
table = doc.add_table(rows=1, cols=3)
table.style = 'Colorful Grid'

hdr_cells = table.rows[0].cells
hdr_cells[0].text = 'Qty'
hdr_cells[1].text = 'Id'
hdr_cells[2].text = 'Desc'
for qty, id, desc in records:
    row_cells = table.add_row().cells
    row_cells[0].text = str(qty)
    row_cells[1].text = id
    row_cells[2].text = desc

# doc.add_paragraph('')
table1 = doc.add_table(rows=1, cols=3)
table1.style = 'Colorful Grid'

hdr_cells = table1.rows[0].cells
hdr_cells[0].text = 'Qty'
hdr_cells[1].text = 'Id'
hdr_cells[2].text = 'Desc'
for qty, id, desc in records:
    row_cells = table1.add_row().cells
    row_cells[0].text = str(qty)
    row_cells[1].text = id
    row_cells[2].text = desc
doc.save("test.docx")

and open the docx afterwards. I am getting one merged table instead of two. See image:

Is this the expected behaviour, and if yes, is there a workaround to have two seperate tables?
Greetings,
Patrick

What does "yest" mean?

typo

Yeah, its kind of a not-expected behaviour, but probably the fault of the docx editor (Word), and not python-docx. I also used a paragraph with 0 font size in the run, to reduce spacing.
It seems this is not a bug, and can therefore be closed :)

To reduce the gap in between, make sure to set line_spacing to 0 or a small number
def split_table(document):      paragraph = document.add_paragraph()     paragraph.paragraph_format.line_spacing = 0     run = paragraph.add_run()     font = run.font     font.size = Pt(0)
`
create table1
split_table(document)
create table2
`

Good afternoon, I tried your way but the "add.paragraph" gives an additional line that I don't want and it doesn't bring close enough the two tables. Does anyone know how to stop auto-merging with non-space consuming way?

authors: AnotherPointofYou HallerPatrick funes79 keithbriggs unicodeee

repo: python-openxml/python-docx


text:
!buildbot PR command matches each word

I didn't investigate very deeply, but it seems that:
Since the 4.0 upgrade, the !buildbot command starts more buildbots than before, while @bedevere-bot's comment lists only ones that would be matched before.
Presumably the comment code and scheduler are now out of sync.

Since the 4.0 upgrade, the !buildbot command starts more buildbots than before

I saw this issue before, I'm not sure that it's a regression caused by the buildbot 4.0 upgrade.

I think this is a consecuence of https://github.com/python/buildmaster-config/issues/419

authors: encukou pablogsal vstinner

repo: python/buildmaster-config


text:
无法使用wd14tager

No problem with startup, no problem with node display, but when you click Run, no picture text information is displayed under WD14Tagger, console has an error
Both cuda and cudnn are the latest versions, and I have also installed this TensorRT-8.6.0.12.Windows10.x86_64. Cuda-12.0, may I ask what else I need to do to use this tag

got prompt
Traceback (most recent call last):
File "F:\ComfyUI\ComfyUI_windows_portable\ComfyUI\execution.py", line 182, in execute
executed += recursive_execute(self.server, prompt, self.outputs, x, extra_data)
File "F:\ComfyUI\ComfyUI_windows_portable\ComfyUI\execution.py", line 67, in recursive_execute
outputs[unique_id] = getattr(obj, obj.FUNCTION)(**input_data_all)
File "F:\ComfyUI\ComfyUI_windows_portable\ComfyUI\custom_nodes\wd14-tagger.py", line 133, in tag
res = tag(image, model, threshold, character_threshold, exclude_tags)
File "F:\ComfyUI\ComfyUI_windows_portable\ComfyUI\custom_nodes\wd14-tagger.py", line 37, in tag
model = InferenceSession(name, providers=ort.get_available_providers())
File "F:\ComfyUI\ComfyUI_windows_portable\python_embeded\lib\site-packages\onnxruntime\capi\onnxruntime_inference_collection.py", line 360, in init
self._create_inference_session(providers, provider_options, disabled_optimizers)
File "F:\ComfyUI\ComfyUI_windows_portable\python_embeded\lib\site-packages\onnxruntime\capi\onnxruntime_inference_collection.py", line 408, in _create_inference_session
sess.initialize_session(providers, provider_options, disabled_optimizers)
RuntimeError: D:\a_work\1\s\onnxruntime\core\session\provider_bridge_ort.cc:1106 onnxruntime::ProviderLibrary::Get [ONNXRuntimeError] : 1 : FAIL : LoadLibrary failed with error 126 "" when trying to load "F:\ComfyUI\ComfyUI_windows_portable\python_embeded\lib\site-packages\onnxruntime\capi\onnxruntime_providers_tensorrt.dll"

Seems like some incompatibility between the DLLs, there are a fair few reports of these errors around, e.g. https://github.com/microsoft/onnxruntime/issues/11826
Can you check that your versions match the onnx requirements
Or you might want to try uninstalling onnxruntime-gpu if you installed that, and just using onnxruntime

Thanks, I'll try it, it feels so good, I'd love to have it

Seems like some incompatibility between the DLLs, there are a fair few reports of these errors around, e.g. microsoft/onnxruntime#11826
Or you might want to try uninstalling onnxruntime-gpu if you installed that, and just using onnxruntime
This seems to provide some more info too: danielgatis/rembg#312 (comment)

worked for me, 10x

I've moved node to a new repo, if there are any more issues please reopen an issue there
https://github.com/pythongosssss/ComfyUI-WD14-Tagger

authors: Natotela laojingwei pythongosssss

repo: pythongosssss/ComfyUI-Custom-Scripts


text:
[Feature Request]

Is there any way to prevent the ShowText node from collapsing every time it is executed?
It is unfortunate that a large portion of the prompt is hidden each time it is executed.
Also, I would like to darken the background if possible to make the text easier to read.

The node shouldnt resize to a smaller size anymore since this update https://github.com/pythongosssss/ComfyUI-Custom-Scripts/commit/7c9adc1f9073d77954f84431872bfb14d4249514
To change the color you can use the ComfyUI/web/user.css file to define your own styles for this,
e.g.
.comfy-multiline-input:read-only {
	color: white;
	background: #111;
	opacity: 1 !important;
}

authors: pythongosssss za-wa-n-go


text:
🛑 Dev Forum is down

In 9087863, Dev Forum (https://devforum.roblox.com/) was down:

HTTP code: 403
Response time: 132 ms

Resolved: Dev Forum is back up in e80459c after 2 minutes.

repo: pythoniaweb/statusboom


text:
Create RFC for plugin support in FX

See AHA! description.
Previous plugin RFC

Pending review from Dheeraj.

RFC can found here: https://github.com/pytorch/TensorRT/discussions/1590

Expecting to complete sprint that started 1/30.

authors: Christina-Young-NVIDIA narendasan

repo: pytorch/TensorRT


text:
Build error on windows (error C2491)

🐛 Bug
Error C2491: definition of dllimport function not allowed when trying to build torchvision

        ]
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/optim/rmsprop.h(52): warning C4251: 'torch::optim::RMSprop::grad_average_buffers' : class 'std::vector<at::Tensor,std::allocator<_Ty>>' nécessite une interface DLL pour être utilisé(e) par les clients de class 'torch::optim::RMSprop'
        with
        [
            _Ty=at::Tensor
        ]
C:\Python37\lib\site-packages\torch\include\ATen/core/Tensor.h(388): note: voir la déclaration de 'std::vector<at::Tensor,std::allocator<_Ty>>'
        with
        [
            _Ty=at::Tensor
        ]
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/optim/sgd.h(31): warning C4275: interface non dll class 'torch::optim::Optimizer' utilisée comme base d'une interface dll class 'torch::optim::SGD'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/optim/optimizer.h(100): note: voir la déclaration de 'torch::optim::Optimizer'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/optim/sgd.h(31): note: voir la déclaration de 'torch::optim::SGD'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/optim/sgd.h(45): warning C4251: 'torch::optim::SGD::momentum_buffers' : class 'std::vector<at::Tensor,std::allocator<_Ty>>' nécessite une interface DLL pour être utilisé(e) par les clients de class 'torch::optim::SGD'
        with
        [
            _Ty=at::Tensor
        ]
C:\Python37\lib\site-packages\torch\include\ATen/core/Tensor.h(388): note: voir la déclaration de 'std::vector<at::Tensor,std::allocator<_Ty>>'
        with
        [
            _Ty=at::Tensor
        ]
Including torch/torch.h for C++ extensions is deprecated. Please include torch/extension.h
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(28): warning C4251: 'vision::models::_resnetimpl::BasicBlock::downsample' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::BasicBlock'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(30): warning C4251: 'vision::models::_resnetimpl::BasicBlock::conv1' : class 'torch::nn::Conv2d' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::BasicBlock'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/conv.h(144): note: voir la déclaration de 'torch::nn::Conv2d'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(30): warning C4251: 'vision::models::_resnetimpl::BasicBlock::conv2' : class 'torch::nn::Conv2d' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::BasicBlock'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/conv.h(144): note: voir la déclaration de 'torch::nn::Conv2d'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(31): warning C4251: 'vision::models::_resnetimpl::BasicBlock::bn1' : class 'torch::nn::BatchNorm' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::BasicBlock'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/batchnorm.h(98): note: voir la déclaration de 'torch::nn::BatchNorm'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(31): warning C4251: 'vision::models::_resnetimpl::BasicBlock::bn2' : class 'torch::nn::BatchNorm' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::BasicBlock'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/batchnorm.h(98): note: voir la déclaration de 'torch::nn::BatchNorm'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(51): warning C4251: 'vision::models::_resnetimpl::Bottleneck::downsample' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::Bottleneck'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(53): warning C4251: 'vision::models::_resnetimpl::Bottleneck::conv1' : class 'torch::nn::Conv2d' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::Bottleneck'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/conv.h(144): note: voir la déclaration de 'torch::nn::Conv2d'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(53): warning C4251: 'vision::models::_resnetimpl::Bottleneck::conv2' : class 'torch::nn::Conv2d' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::Bottleneck'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/conv.h(144): note: voir la déclaration de 'torch::nn::Conv2d'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(53): warning C4251: 'vision::models::_resnetimpl::Bottleneck::conv3' : class 'torch::nn::Conv2d' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::Bottleneck'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/conv.h(144): note: voir la déclaration de 'torch::nn::Conv2d'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(54): warning C4251: 'vision::models::_resnetimpl::Bottleneck::bn1' : class 'torch::nn::BatchNorm' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::Bottleneck'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/batchnorm.h(98): note: voir la déclaration de 'torch::nn::BatchNorm'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(54): warning C4251: 'vision::models::_resnetimpl::Bottleneck::bn2' : class 'torch::nn::BatchNorm' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::Bottleneck'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/batchnorm.h(98): note: voir la déclaration de 'torch::nn::BatchNorm'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(54): warning C4251: 'vision::models::_resnetimpl::Bottleneck::bn3' : class 'torch::nn::BatchNorm' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::_resnetimpl::Bottleneck'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/batchnorm.h(98): note: voir la déclaration de 'torch::nn::BatchNorm'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(188): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>::conv1' : class 'torch::nn::Conv2d' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/conv.h(144): note: voir la déclaration de 'torch::nn::Conv2d'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(188): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>::bn1' : class 'torch::nn::BatchNorm' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/batchnorm.h(98): note: voir la déclaration de 'torch::nn::BatchNorm'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(188): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>::fc' : class 'torch::nn::Linear' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/linear.h(54): note: voir la déclaration de 'torch::nn::Linear'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(188): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>::layer1' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(188): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>::layer2' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(188): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>::layer3' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(188): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>::layer4' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::BasicBlock>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(196): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>::conv1' : class 'torch::nn::Conv2d' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/conv.h(144): note: voir la déclaration de 'torch::nn::Conv2d'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(196): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>::bn1' : class 'torch::nn::BatchNorm' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/batchnorm.h(98): note: voir la déclaration de 'torch::nn::BatchNorm'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(196): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>::fc' : class 'torch::nn::Linear' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/linear.h(54): note: voir la déclaration de 'torch::nn::Linear'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(196): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>::layer1' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(196): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>::layer2' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(196): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>::layer3' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(196): warning C4251: 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>::layer4' : class 'torch::nn::Sequential' nécessite une interface DLL pour être utilisé(e) par les clients de struct 'vision::models::ResNetImpl<vision::models::_resnetimpl::Bottleneck>'
C:\Python37\lib\site-packages\torch\include\torch\csrc\api\include\torch/nn/modules/sequential.h(360): note: voir la déclaration de 'torch::nn::Sequential'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(22): warning C4273: 'expansion' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(33): note: voir la définition précédente de 'public: static int vision::models::_resnetimpl::BasicBlock::expansion'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(22): error C2491: 'vision::models::_resnetimpl::BasicBlock::expansion' : définition de données membres static dllimport non autorisée
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(23): warning C4273: 'expansion' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(56): note: voir la définition précédente de 'public: static int vision::models::_resnetimpl::Bottleneck::expansion'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(23): error C2491: 'vision::models::_resnetimpl::Bottleneck::expansion' : définition de données membres static dllimport non autorisée
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(32): warning C4273: 'vision::models::_resnetimpl::BasicBlock::BasicBlock' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(35): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(63): warning C4273: 'vision::models::_resnetimpl::Bottleneck::Bottleneck' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(58): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(87): warning C4273: 'vision::models::_resnetimpl::Bottleneck::forward' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(66): note: voir la définition précédente de 'forward'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(106): warning C4273: 'vision::models::_resnetimpl::BasicBlock::forward' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(43): note: voir la définition précédente de 'forward'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(124): warning C4273: 'vision::models::ResNet18Impl::ResNet18Impl' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(189): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(127): warning C4273: 'vision::models::ResNet34Impl::ResNet34Impl' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(193): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(130): warning C4273: 'vision::models::ResNet50Impl::ResNet50Impl' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(197): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(133): warning C4273: 'vision::models::ResNet101Impl::ResNet101Impl' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(201): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(136): warning C4273: 'vision::models::ResNet152Impl::ResNet152Impl' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(205): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(141): warning C4273: 'vision::models::ResNext50_32x4dImpl::ResNext50_32x4dImpl' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(209): note: voir la définition précédente de '{ctor}'
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.cpp(146): warning C4273: 'vision::models::ResNext101_32x8dImpl::ResNext101_32x8dImpl' : liaison DLL incohérente
C:\Users\Jonas\Desktop\vision\torchvision\csrc\models\resnet.h(215): note: voir la définition précédente de '{ctor}'
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.21.27702\\bin\\HostX86\\x64\\cl.exe' failed with exit status 2

C:\Users\Jonas\Desktop\vision>

To Reproduce
Steps to reproduce the behavior:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
set NVCC_FLAGS=-D__CUDA_NO_HALF_OPERATORS__ --expt-relaxed-constexpr -gencode=arch=compute_35,code=sm_35 -gencode=arch=compute_50,code=sm_50 -gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_70,code=sm_70 -gencode=arch=compute_75,code=sm_75 -gencode=arch=compute_50,code=compute_50
python setup.py install

Expected behavior

Environment

PyTorch Version (e.g., 1.0): '1.2.0.dev20190701'
OS (e.g., Linux): windows
How you installed PyTorch (conda, pip, source): pip
Build command you used (if compiling from source):
Python version: 3.7.3
CUDA/cuDNN version: 10.1
GPU models and configuration: 940mx
Any other relevant information:

Can you comment out
https://github.com/pytorch/vision/blob/55088157c09c9368fdffaaaaacf5f7f3db641aac/setup.py#L92-L99
and https://github.com/pytorch/vision/blob/55088157c09c9368fdffaaaaacf5f7f3db641aac/setup.py#L131-L138
and let me know if this works?
Also, cc @ShahriarSS as this seems to be a problem with the C++ models

@fmassa it's working, thanks!
BTW I had to comment out line 121 also https://github.com/pytorch/vision/blob/55088157c09c9368fdffaaaaacf5f7f3db641aac/setup.py#L121

Hey, would you please try adding the defined macro 'torchvision_EXPORTS', that is to add the following code block before this line https://github.com/pytorch/vision/blob/55088157c09c9368fdffaaaaacf5f7f3db641aac/setup.py#L123:
define_macros += [('torchvision_EXPORTS', None)]

If that works, I'll file a new PR.

@peterjc123 if this fixes the problem, it's great!
My previous post disabled the C++ models build in torchvision, which is only used for testing it on CI and is not used in the torchvision code. So the functionality should be the same I believe

@peterjc123 your fix works 🙂

@fmassa I don't have a set up windows environment and this is related to this PR. It seems that @peterjc123  has the solution.

repo: pytorch/vision


text:
Can KeypointRCNN also detect objects that do not need to be predicted with keypoints?

As far as I understand keypoints would be computed for all the box classes (apart from background) in Keypoint-RCNN. I need to do object detection and keypoint prediction at the same time, however keypoints should only be predicted for one class. Does current version support this?
If not, I would need to modify some of the code in FasterRCNN and KeypointRCNN as far as I understand but in principle it is possible, right?

Your keypoint rcnn just inferences predicted boxed rather than keypoints? if true, why don't you use faster rcnn instead of keypoint rcnn?

Hi,
KeypointRCNN only has the person class. Thus, it only computes keypoints for the person class as well.
If you want to detect multiple objects and keypoints for a single object, then you'll need to either pass two detectors, or modify keypoint rcnn to handle this situation.

authors: JasperShian anuar12 fmassa


text:
Revert "Remove performance workaround for mask resize"

Reverts pytorch/vision#6729
We are putting the performance workaround back because the mitigation on PyTorch Core was reverted: https://github.com/pytorch/pytorch/pull/86361
Let's keep this workaround in until the mitigation is permanently landed on Core.

It seems that the original PR got relanded. I'm closing this for now.


text:
Unable to click/interact with QT App

Expected Behavior
Click action performed by pywinauto.
Actual Behavior
No click action happens, nor any interaction for that matter.
Steps to Reproduce the Problem

Substitute anki_Path with the path to Anki application
Run code

Short Example of Code to Demonstrate the Problem
The following are two different implementantions of the code, I've included them both since both of them return different objects when printing anki.
anki_App = Application(backend="uia").start(anki_Path)
anki = anki_App.window(title_re=r".* - Anki", class_name="AnkiQt").wait('Active', timeout=20, retry_interval=0.5)
anki['Import File'].click_input()

First one returns: <pywinauto.application.WindowSpecification object at 0x02E63820>
anki_App = Application(backend="uia").start(anki_Path)
anki_App.top_window().wait("Visible") #Wait for Anki's sync to server
anki = anki_App.window(title_re=r".* - Anki", class_name="AnkiQt")
anki['Import File'].click_input()

Second one returns: uiawrapper.UIAWrapper - 'User 1 - Anki', Dialog
Specifications

Pywinauto version: 0.6.8
Python version and bitness: Python 3.8.2 64-bit
Platform and OS: Windows 10
Control identifiers for reference
Thank you for your time.

Didn't have much time to dig, but I might see the problem. The coordinates are probably wrong:

Thank You!! I was able to fix it using:
anki_App = Application(backend="uia").start(anki_Path)
anki_App.top_window().wait("Visible") #Wait for Anki's sync to server
anki = anki_App.window(title_re=r".* - Anki", class_name="AnkiQt")
anki['Browse'].draw_outline()
anki['Browse'].click_input(coords=(anki['Browse'].rectangle().left -1, anki['Browse'].rectangle().top -1), absolute = True)

I'm not sure how optimal of a solution it actually is... But I'm glad I'm making progress! Thank you so much!

authors: RakuTheSenpai airelil

repo: pywinauto/pywinauto


text:
improved code-cov

Improved Code coverage to somewhere around 98%

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 96.67%. Comparing base (56fc987) to head (6ea0428).

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #60      +/-   ##
==========================================
+ Coverage   92.95%   96.67%   +3.72%
==========================================
  Files          10       10
  Lines         284      271      -13
==========================================
- Hits          264      262       -2
+ Misses         20        9      -11

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

repo: qBraid/qbraid-qir


text:
Timezone not including GMT-1200

I get every number from -1100 to +1200, but not -1200. Running 0.4.1.
Also shouldn't the timezones really be proper text like Pacific/Auckland, rather than just numbers?

I'm pulling a list of standard time zones from the system - on Windows, it displays this:

Can you share a screenshot of what it looks like on your system? I may need to just hard-code this list if Linux-based systems don't have a nice list like this. 🙂

@nickrout I see what you're saying - on Linux, it doesn't display the names of the timezones, but my list goes from UTC-11 to UTC+14 (weirdly), and maybe I'm not that familiar with timezones, but aren't UTC+12 and UTC-12 equivalent? Can you try UTC+12:00 and let me know if that works and displays the correct time?
Also, some people have had success mapping this volume with Docker: "/etc/localtime:/etc/localtime:ro" You can also set the TZ environment variable which may work as well.

authors: nickrout qJake


text:
🛑 nitter.domain.glass is down

In b8a9ea5, nitter.domain.glass (https://nitter.domain.glass) was down:

HTTP code: 503
Response time: 359 ms

Resolved: nitter.domain.glass is back up in 387d0ea after 8 hours, 36 minutes.


text:
🛑 nitter.ir is down

In c9a1fd0, nitter.ir (https://nitter.ir) was down:

HTTP code: 0
Response time: 0 ms

Resolved: nitter.ir is back up in 5cfefa5 after 11 minutes.


text:
🛑 notabird.site is down

In 7401326, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 75 ms

Resolved: notabird.site is back up in 7b45323.


text:
🛑 notabird.site is down

In e5f6d8a, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 82 ms

Resolved: notabird.site is back up in 0034436.


text:
🛑 notabird.site is down

In e534e56, notabird.site (https://notabird.site) was down:

HTTP code: 520
Response time: 100 ms

Resolved: notabird.site is back up in 13ace0c after 30 minutes.


text:
🛑 nitter.us.projectsegfau.lt is down

In 68ce3d5, nitter.us.projectsegfau.lt (https://nitter.us.projectsegfau.lt) was down:

HTTP code: 502
Response time: 370 ms

Resolved: nitter.us.projectsegfau.lt is back up in 555193b after 1 hour, 23 minutes.


text:
🛑 nitter.pw is down

In 93d4222, nitter.pw (https://nitter.pw) was down:

HTTP code: 404
Response time: 462 ms

Resolved: nitter.pw is back up in f65304f.


text:
Feature request: Remove port forwarding data on container run/stop

What's the feature?

When running the container, if the PORT_FORWARDING_STATUS_FILE variable is specified, clear the data in the associated PORT_FORWARDING_STATUS_FILE volume.
When stopping/killing the container, if the PORT_FORWARDING_STATUS_FILE variable is specified, clear the data in the associated PORT_FORWARDING_STATUS_FILE volume.

Why do you need this feature?
The forwarded port data may be stale.  Another app may be reading the PORT_FORWARDING_STATUS_FILE volume to allow communication over the forwarded port, and think communication is possible, when in fact it isn't causing preventable failures.
Example 1

Run the container specifying a valid port forwarding server with the PORT_FORWARDING_STATUS_FILE variable specified.

The forwarded port is queried and written to the associated PORT_FORWARDING_STATUS_FILE volume.

Stop the container.
Run the container specifying a valid port forwarding server with the PORT_FORWARDING_STATUS_FILE variable specified.

The forwarded port is queried, however the query fails.
The port from the first run will still be in the PORT_FORWARDING_STATUS_FILE volume even though it is not valid for the current connection.

Example 2

Run the container specifying a valid port forwarding server with the PORT_FORWARDING_STATUS_FILE variable specified.

The forwarded port is queried and written to the associated PORT_FORWARDING_STATUS_FILE volume.

Stop the container.
Run the container specifying any server without the PORT_FORWARDING_STATUS_FILE variable specified.

The port from the first run will still be in the PORT_FORWARDING_STATUS_FILE volume even though it is not valid for the current connection.

Thanks for the detailed issue!
I think the feature is more to remove the content of the port forwarded file whether PORT_FORWARDING_STATUS_FILE is defined or not, at container start time (before querying the port etc.).
I implemented the changes, but just one last question: do you also need the file to be emptied once the container stops/exits or no?
Thanks!

Practically, for me, no I don't need it emptied on stop/exit.
However, with regard to having accurate data coming from the VPN client, yes, I think it should be cleared whenever there is not a currently forwarded port (i.e. connection start and stop ... and the port forwarding routine should fill it in if applicable for that connection).

In the end, I just added a clear of the port forward status file when the container exits (even when killed, it should clear the file). That way, there is no need to clear it at start as a previous run with port forwarding enabled should had cleared it up. Let me know if you need anything else on that matter 👍