Looks cleaner! I run NumberVersion benchmark and saw no changes in performance with the latest commit and without:

Benchmarking large_cases/large_case_u16_NumberVersion.ron: Analyzing
large_cases/large_case_u16_NumberVersion.ron
                        time:   [10.390 ms 10.417 ms 10.445 ms]
                        change: [-0.4907% -0.1013% +0.2715%] (p = 0.62 > 0.05)
                        No change in performance detected.
Found 11 outliers among 100 measurements (11.00%)
  1 (1.00%) low mild
  4 (4.00%) high mild
  6 (6.00%) high severe

I don't have other benchmarks mentioned on Zulip though (zuse?), where can I get them?

Here is the code cleanup I mentioned in the previous PR

There are proposals in CPython to enforce correct types (str, bytes, bytearray) in urllib.parse: bpo-19094 and bpo-22234. None is not valid (and not returned by urlsplit(), which is how urlunsplit() is documented).

https://bugs.python.org/issue19094 https://bugs.python.org/issue22234

This point of this PR is to get ahead of those potential changes.

<!--- Thank you for your soon to be pull request. Before you submit this, please double check to make sure that you've added a news file fragment. In pip we generate our NEWS.rst from multiple news fragment files, and all pull requests require either a news file fragment or a marker to indicate they don't require one.

To read more about adding a news file fragment for your PR, please check out our documentation at: https://pip.pypa.io/en/latest/development/contributing/#news-entries -->

And we do want to improve in this are -- there's other issues tracking that (like https://github.com/pypa/pip/issues/7294).

Contrary to the docs, the .trivial file needs to have some dummy content (because there's a bug in the check).

I'm fine with this, although the bpo issues seem very old, and honestly it doesn't seem worth the breakage such a change would cause. But defending against them making this change seems harmless enough.

There are proposals in CPython to enforce correct types (str, bytes, bytearray) in urllib.parse: bpo-19094 and bpo-22234. None is not valid (and not returned by urlsplit(), which is how urlunsplit() is documented).

https://bugs.python.org/issue19094 https://bugs.python.org/issue22234

This point of this PR is to get ahead of those potential changes.

<!--- Thank you for your soon to be pull request. Before you submit this, please double check to make sure that you've added a news file fragment. In pip we generate our NEWS.rst from multiple news fragment files, and all pull requests require either a news file fragment or a marker to indicate they don't require one.

To read more about adding a news file fragment for your PR, please check out our documentation at: https://pip.pypa.io/en/latest/development/contributing/#news-entries -->

Yes. When building using PEP 517/518, the build requirements (which are usually specified in pyproject.toml, but which will default to setuptools' "legacy" backend if not specified) may not be installed in the user's current environment. So pip installs them into a virtual environment and builds with that - that obviously takes some extra time. --no-build-isolation skips that virtual environment build step, but the cost is that the build will fail if you don't have all of the necessary dependencies installed (and in extreme cases that may not even be possible, if two requirements depend on, for example, different versions of setuptools to build).

While it would be nice to avoid the cost of setting up a build environment when it's not needed, it's frankly not been a significant issue for anyone until this point, and it would be hard to do so reliably. The legacy build process did none of this - it just tried the build in the environment the project was being installed into, and if that failed, tough. Of course, for simpler projects like your example, this worked fine. But for more complex projects it was an issue.

Adding --no-build-isolation removes the gap entirely:

Benchmark #1: pip wheel --use-feature=in-tree-build -w dist/ --only-binary ":all:" --no-deps -r requirements.txt . --no-use-pep517
  Time (mean ± σ):      1.622 s ±  0.086 s    [User: 1.170 s, System: 0.331 s]
  Range (min … max):    1.522 s …  1.776 s    10 runs
 
Benchmark #2: pip wheel --use-feature=in-tree-build -w dist/ --only-binary ":all:" --no-deps -r requirements.txt . --use-pep517 --no-build-isolation
  Time (mean ± σ):      1.620 s ±  0.049 s    [User: 1.166 s, System: 0.325 s]
  Range (min … max):    1.546 s …  1.702 s    10 runs
 
Summary
  'pip wheel --use-feature=in-tree-build -w dist/ --only-binary ":all:" --no-deps -r requirements.txt . --use-pep517 --no-build-isolation' ran
    1.00 ± 0.06 times faster than 'pip wheel --use-feature=in-tree-build -w dist/ --only-binary ":all:" --no-deps -r requirements.txt . --no-use-pep517'

Is this expected?

Pushing this reasoning a bit further I wonder if we should not be even stricter and says that parallel installation can only be enabled when all InstallRequirement are wheels (and are not already legacy installed).

I like this idea - it's a lot cleaner, and it emphasises that the legacy code paths are just that - legacy, and people shouldn't expect to see new features/improvements like this unless they move away from the legacy approaches. Encouraging people to use more modern approaches would be an extra benefit of this change, if we took that route.

Sorry for the slow turnaround here.

not all requirements can be parallelized

I understand that. Nevertheless I suspect the code could be made easier to understand and maintain by doing something like

parallel_req, sequential_reqs = split_reqs()
parallel_results = install_parallel(parallel_req)
sequential_results = install_sequential(sequential_reqs)
# merge and print results...

Also, in terms of correctness, installation may imply uninstallation. And in some cases, uninstallation may not be multiprocess-safe ? I'm thinking in particular to the uninstallation of packages that were installed with setup.py develop and are replaced by a parallel wheel installation. I you have several of them there might be concurrency issues on easy-install.pth (see UninstallPthEntries). So we probably want to also exclude packages that are legacy installed from parallel installation.

Pushing this reasoning a bit further I wonder if we should not be even stricter and says that parallel installation can only be enabled when all InstallRequirement are wheels (and are not already legacy installed). This would give us a clean code path without legacy baggage for parallel installation, and we can keep the legacy path untouched.

Quoting from https://github.com/pypa/pip/issues/10059#issuecomment-860049295:

pip's issue tracker isn't the right place to ask for help with this sort of thing.

Something like Python Discord's #help-* channels or the python-tutor mailing list would be better channels to get support for the issue you're facing.

Description

hoever I installed conan successfully (checked with "pip list --verbose" command, I get this error where is the issue? I should mention that I am new user so need a thorough help!

Expected behavior

I want to test conan package and upload to Bintray by these comands:

conan create . nrel/testing conan test test_package openstudio_ruby/2.5.5@nrel/stable conan remote add <REMOTE> <YOUR_BINTRAY_REPO_URL> conan user -p <APIKEY> -r <REMOTE> <USERNAME> conan download -r conan-center zlib/1.2.11@

... etc

but I get error!

pip version

21.1.2

Python version

3.8.6

OS

windows

How to Reproduce

1. when I run the "conan create" command, it sould automatically run the tests against the package it built right after. From the root of the repo.
2. but I get this error: 'conan' is not recognized as an internal or external command, operable program or batch file.

Output

Description

I am trying to install conan from its source (after failed installation with pip!) it gies me a message

-e option requires 1 argument

what does it mean?

I should mention that I am new user and need a thorough help!

Thanks

Expected behavior

conan installation

pip version

21.1.2

Python version

3.8.6

OS

windows

How to Reproduce

1. git clone https://github.com/conan-io/conan.git conan_src
2. cd conan_src
3. python -m pip install -e
4. I get message bellow:

Output

Usage:
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] <requirement specifier> [package-index-options] ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] -r <requirements file> [package-index-options] ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] [-e] <vcs project url> ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] [-e] <local project path> ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] <archive url/path> ...

-e option requires 1 argument

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

The -e option takes an argument. The instructions on https://pypi.org/project/conan/ show that (although it's hard to see, as the argument is a single dot ".") Your command should be python -m pip install -e .

But see my response on #10061 - you need to ask on a support forum for the package for this type of help.

Description

I coned an app repository from github. set the location of source code and binaries

When configuring the file in CMske, I get an error!

It seems version's incompatibility! But it does not make sense.

I installed CMake 3.20.3 and conan 1.37.1

Expected behavior

Configure the project in CMake

pip version

21.1.2

Python version

3.8.6

OS

windows

How to Reproduce

1. set the location of source code and binaries
2. hit "configure" bottom
3. An error occurs.

Output

Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
Found specified openstudio at openstudio_DIR=C:/Users/MAEDEH/OpenStudioApplication/build/OpenStudio-3.2.0/OpenStudio-3.2.0+e11f0a08b2-Windows/lib/cmake/openstudio
Found openstudio CLI with the exact expected long version:
  version: 3.2.0+e11f0a08b2
  openstudio_EXECUTABLE: "C:/Users/MAEDEH/OpenStudioApplication/build/OpenStudio-3.2.0/OpenStudio-3.2.0+e11f0a08b2-Windows/bin/openstudio.exe"

CONAN_PRINT_RUN_COMMANDS: 
openstudio: using existing conan.cmake
Conan: checking conan executable
Conan: Found program C:/Users/MAEDEH/AppData/Roaming/Python/Python38/Scripts/conan.exe
Conan: Version found failed to create process.

CMake Error at build/conan.cmake:816 (if):
  if given arguments:

    "VERSION_LESS" "1.28.0"

  Unknown arguments specified
Call Stack (most recent call first):
  ConanInstall.cmake:26 (conan_check)
  CMakeLists.txt:62 (include)


Configuring incomplete, errors occurred!
See also "C:/Users/MAEDEH/OpenStudioApplication/build/CMakeFiles/CMakeOutput.log".

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

See my response on #10061 - you need to ask on a support forum for the package.

You should be asking in a support forum for the "conan" package - this is not an issue with pip. The PyPI page https://pypi.org/project/conan/ has a link to a slack channel which may be of help.

This is probably caused by build isolation (which is used in PEP 517 builds but not in the "legacy" code path, if I remember correctly). Does performance improve if you use --no-build-isolation?

(Please understand that I'm asking for diagnosis purposes - you most definitely should not recommend using --no-build-isolation simply as a way of speeding up builds).

Would be great to get the conversation going :-)

Description

I am trying to install conan from its source (after failed installation with pip!) it gies me a message

-e option requires 1 argument

what does it mean?

I should mention that I am new user and need a thorough help!

Thanks

Expected behavior

conan installation

pip version

21.1.2

Python version

3.8.6

OS

windows

How to Reproduce

1. git clone https://github.com/conan-io/conan.git conan_src
2. cd conan_src
3. python -m pip install -e
4. I get message bellow:

Output

Usage:
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] <requirement specifier> [package-index-options] ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] -r <requirements file> [package-index-options] ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] [-e] <vcs project url> ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] [-e] <local project path> ...
  C:\Users\MAEDEH\python38\python.exe -m pip install [options] <archive url/path> ...

-e option requires 1 argument

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

@jeffamstutz

You can upload a post version, v0.1.3.post1 - this will be treated like the original, --upgrade will know they are the same, etc. You can also upload missing files without starting a new version if one or more wheels didn't upload (or the SDist).

Description

When configuring the file in CMske, I get an error!

It seems version's incompatibility! But it does not make sense.

I installed CMake 3.20.3 and conan 1.37.1

Expected behavior

Configure the project in CMake

pip version

21.1.2

Python version

3.8.6

OS

windows

How to Reproduce

1. set the location of source code ans binaries
2. hit "configure" bottom
3. An error occurs.

Output

Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
Found specified openstudio at openstudio_DIR=C:/Users/MAEDEH/OpenStudioApplication/build/OpenStudio-3.2.0/OpenStudio-3.2.0+e11f0a08b2-Windows/lib/cmake/openstudio
Found openstudio CLI with the exact expected long version:
  version: 3.2.0+e11f0a08b2
  openstudio_EXECUTABLE: "C:/Users/MAEDEH/OpenStudioApplication/build/OpenStudio-3.2.0/OpenStudio-3.2.0+e11f0a08b2-Windows/bin/openstudio.exe"

CONAN_PRINT_RUN_COMMANDS: 
openstudio: using existing conan.cmake
Conan: checking conan executable
Conan: Found program C:/Users/MAEDEH/AppData/Roaming/Python/Python38/Scripts/conan.exe
Conan: Version found failed to create process.

CMake Error at build/conan.cmake:816 (if):
  if given arguments:

    "VERSION_LESS" "1.28.0"

  Unknown arguments specified
Call Stack (most recent call first):
  ConanInstall.cmake:26 (conan_check)
  CMakeLists.txt:62 (include)


Configuring incomplete, errors occurred!
See also "C:/Users/MAEDEH/OpenStudioApplication/build/CMakeFiles/CMakeOutput.log".

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

Description

hoever I installed conan successfully (checked with "pip list --verbose" command, I get this error where is the issue? I should mention that I am new user so need a thorough help!

Expected behavior

I want to test conan package and upload to Bintray by these comands:

conan create . nrel/testing conan test test_package openstudio_ruby/2.5.5@nrel/stable conan remote add <REMOTE> <YOUR_BINTRAY_REPO_URL> conan user -p <APIKEY> -r <REMOTE> <USERNAME> conan download -r conan-center zlib/1.2.11@

... etc

but I get error!

pip version

21.1.2

Python version

3.8.6

OS

windows

How to Reproduce

1. when I run the "conan create" command, it sould automatically run the tests against the package it built right after. From the root of the repo.
2. but I get this error: 'conan' is not recognized as an internal or external command, operable program or batch file.

Output

Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
Found specified openstudio at openstudio_DIR=C:/Users/MAEDEH/OpenStudioApplication/build/OpenStudio-3.2.0/OpenStudio-3.2.0+e11f0a08b2-Windows/lib/cmake/openstudio
Found openstudio CLI with the exact expected long version:
  version: 3.2.0+e11f0a08b2
  openstudio_EXECUTABLE: "C:/Users/MAEDEH/OpenStudioApplication/build/OpenStudio-3.2.0/OpenStudio-3.2.0+e11f0a08b2-Windows/bin/openstudio.exe"

CONAN_PRINT_RUN_COMMANDS: 
openstudio: using existing conan.cmake
Conan: checking conan executable
Conan: Found program C:/Users/MAEDEH/AppData/Roaming/Python/Python38/Scripts/conan.exe
Conan: Version found failed to create process.

CMake Error at build/conan.cmake:816 (if):
  if given arguments:

    "VERSION_LESS" "1.28.0"

  Unknown arguments specified
Call Stack (most recent call first):
  ConanInstall.cmake:26 (conan_check)
  CMakeLists.txt:62 (include)


Configuring incomplete, errors occurred!
See also "C:/Users/MAEDEH/OpenStudioApplication/build/CMakeFiles/CMakeOutput.log".

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

I've been thinking about this a little more and I'm not so sure it's worth supporting completely arbitrary versioning with how much work it seems to require.

For some reason I think I had overcomplicated how hard it would be to implement a "punctured" range--a range that has some versions missing (such as release candidates). I think I see a path forward for implementing PEP 440 that way, and semver should be even easier.

This of course would make it difficult to implement completely arbitrary versioning, but I'm pretty sure most standards are based on ranges in some form or another...

Personally, I think I prefer (in no particular order):

• Normal dictionary, tri-state per value (since deleting keys for fields will very likely be rare, but deleting from dynamic will come up)
• Data object, tri-state per attribute (because it's simple and alleviates the concerns brought up)
• Data object, get/set/whatever as appropriate per field (alleviates all of the concerns, hard to get the data wrong)