cryptography v38.0.1

[regro-cf-autotick-bot]

It is very likely that the current package version for this feedstock is out of date.

Checklist before merging this PR:

• Dependencies have been updated if changed: see upstream
• Tests have passed
• Updated license if changed and license_file is packaged

Information about this PR:

1. Feel free to push to the bot's branch to update this PR if needed.
2. The bot will almost always only open one PR per version.
3. The bot will stop issuing PRs if more than 3 version bump PRs generated by the bot are open. If you don't want to package a particular version please close the PR.
4. If you want these PRs to be merged automatically, make an issue with @conda-forge-admin,please add bot automerge in the title and merge the resulting PR. This command will add our bot automerge feature to your feedstock.
5. If this PR was opened in error or needs to be updated please add the bot-rerun label to this PR. The bot will close this PR and schedule another one. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

Closes: #103

Pending Dependency Version Updates

Here is a list of all the pending dependency version updates for this repo. Please double check all dependencies before merging.

Name	Upstream Version	Current Version
cryptography-vectors	38.0.1

Dependency Analysis

Please note that this analysis is highly experimental. The aim here is to make maintenance easier by inspecting the package's dependencies. Importantly this analysis does not support optional dependencies, please double check those before making changes. If you do not want hinting of this kind ever please add bot: inspection: false to your conda-forge.yml. If you encounter issues with this feature please ping the bot team conda-forge/bot.

Analysis by source code inspection shows a discrepancy between it and the the package's stated requirements in the meta.yaml.

Packages found by source code inspection but not in the meta.yaml:

• cryptography-vectors
• click
• urllib3
• requests
• privy

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/autotick-bot/actions/runs/3008460515, please use this URL for debugging.}

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ocefpaf]

@conda-forge-admin, please restart ci

[thewchan]

@h-vetinari @ocefpaf @jakirkham Any chance of fixing this? There are some packages waiting for this new version as dependencies

[h-vetinari]

@conda-forge-admin, please rerender

[github-actions]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/cryptography-feedstock/actions/runs/3150339477.

[h-vetinari]

Any chance of fixing this?

Sorry this fell through the cracks. It's been far too low on my to-do list, but if we ever get to it, it would be good to just package the cryptography-vectors package from this feedstock directly

[h-vetinari]

Ugh, completely useless error message...

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise>CALL "VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=14.29 10.0.22621.0 
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.11.19
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
The input line is too long.
The syntax of the command is incorrect.
Traceback (most recent call last):

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: failed

Thus the PR was not passing and not merged.

[pkgw]

Googling says that the line is too long error can happen if you run the vcvars script repeatedly, and we are running it twice. Is that our problem? (In the linked example, they only hit a problem after running the script many times, but our various path-y environment variables might be a lot longer than most people's?)

But then ... why did this start happening relatively recently?

(I'm also seeing this with conda-forge/tectonic-feedstock#55.)

update: FWIW, in the most recent successful Windows build of Tectonic, vcvars64.bat is only invoked once. The successful build uses conda-build 3.21.9, while the failing one uses 3.22.0.

update 2: Nothing in the conda-build 3.22 changelog sounds relevant to the change in behavior. Another potentially-important difference in the Tectonic feedstock is that setuptools jumps from 62.3.2 to 65.4.1.

[github-actions]

Hi! This is the friendly conda-forge automerge bot!

Commits were made to this PR after the automerge label was added. For security reasons, I have disabled automerge by removing the automerge label. Please add the automerge label again (or ask a maintainer to do so) if you'd like to enable automerge again!

[ocefpaf]

Probably won't work. I thought that the D: use case was deep nested into subdirs :-/

[pkgw]

Is there a way to pin the version of setuptools used by the build process? My theory is that downgrading to 62.x might make the problem go away. Pinning here wouldn't be a real fix, of course, but it would be nice to be able to test the theory.

[ocefpaf]

We can pin but yeah, ideally we should fix this for good. Trying that now...

[pkgw]

The pin I was thinking of would apply to the builder's environment — i.e. the Python process invoking conda-build, not the host environment of the package. I think maybe something changed in setuptools that caused conda-build to do the vcvars setup twice, leading to the issue.

[ocefpaf]

Sorry, did not pay enough attention to the issue. We can pin but that would be a bit disruptive. I'll hack the CIs here tomorrow to test if this fixes it.

[pkgw]

@ocefpaf See below, no need — I think I was on the wrong trail anyway.

[pkgw]

OK, well I sat down with a Windows VM, and it looks like my setuptools theory was wrong anyway. As far as I can tell, the double-invocation of vcvars64 is caused by the change of c_compiler from vs2017 to vs2019 in the .ci_support files.

I think this makes sense since rust_win-64 depends on vs2017_win-64, so we're getting two Visual Studio setup packages installed in the build environment:

    vs2017_win-64:                   19.16.27033-hb90652a_7 conda-forge
    vs2019_win-64:                   19.29.30139-hb9aee9d_7 conda-forge

Is it appropriate to remove the {{ compiler('c') }} line, since Rust kind of implicitly includes it? If I do that and rerender, the c_compiler: vs2019 setting goes away, so I think that will fix the double-invocation issue. And hopefully that will fix the "line too long" error ...

[pkgw]

Also, here is where the Rust activation script seems to get tied to vs2017, if it would be better to update that to vs2019.

update: oh great, @h-vetinari I see that you are one of the experts on this. Reading conda-forge/conda-forge.github.io#1732 I get the strong impression that rust-activation should be updated to vs2019. Do you agree?

update 2: I've gone ahead and filed a PR, conda-forge/rust-activation-feedstock#28

[h-vetinari]

Also, here is where the Rust activation script seems to get tied to vs2017, if it would be better to update that to vs2019.

Yes that absolutely sounds like the right way to go! :)

[h-vetinari]

update 2: I've gone ahead and filed a PR, conda-forge/rust-activation-feedstock#28

Thank you (both for the analysis & the PR)! :)

Let's see if this feedstock is looking better again now!