RE: python-cryptography >= 3.4.0 and Rust
> -Original Message- > From: Cygwin-apps > On Behalf Of Marco Atzeri > Sent: Friday, February 4, 2022 4:28 PM > To: cygwin-apps@cygwin.com > Subject: Re: python-cryptography >= 3.4.0 and Rust > > On 04.02.2022 16:28, Allen Hewes wrote: > >> -Original Message- > > >>> > >>> Welp, then the wheels came off. I am assuming that Cygwin's python- > >> cryptography is still at 3.3.2 b/c of this Rust issue? > >>> > >> > >> Hi Allen, > >> it is correct. I released the last version that was still on C > >> > > > > It's still on C but the authors have been adding new features in Rust. They > are using the Python Rust API bridge for the integration between the two. > > > > It seems not an optional feature, without a Rust compiler it can not be built > Or perhaps the build process could be changed to exclude the Rust bits? I don't know if this possible or not or what it would mean to exclude them. Just thinking out loud. > >>> Rust is making more in-roads into software I use frequently or like > >>> to use. Is > >> there any efforts or discussions about getting Rust able to target Cygwin? > >> > >> Not that I aware of. > >> We have already problem to update clang that is already behind. > >> > > > > Many of the shiny new sysadmin/sysutils are written in Rust or Go. > > > > The reason why I brought up python cryptography and Cygwin is that the > current version of python cryptography doesn't support OpenSSL 3 (AFAIK). > Only the most recent cryptography does. At some point in the future, this > will have to be addressed, wouldn't it (IMHO)? Python cryptography is > fundamental in the Python ecosystem. Pythonistas who use Cygwin will > need an update to cryptography. How can this happen? > >"Somebody Has To Do It" https://cygwin.com/acronyms/#SHTDI > > but I do not volounteer ... > No suggestion to you or others to work on it was intended. I was asking more rhetorically to start a conversation about what the effort might look like b/c maybe I could contribute. If the only acceptable effort for Cygwin is to port Rust, I can't contribute in a meaningful way. But if there are other ideas (even crazy ones), I might be able to contribute. > >> Rust and Go are purely wish, they both requires specific expertize and > time. > >> > > > > ...except for then those languages make in-roads into the bits/ecosystem > that Cygwin has packaged/supported (for a long time in some cases). From > what I can tell, these ecosystems think WSL/WSL2 is their "best effort" for > Linux-y (or POSIX) on Windows. > > > >> Feel free to work on it > > > > Based on the conversation in rigrep (a Rust grepper), it sounds like it's a > large amount of work that would not be accepted/entertained by upstream: > > https://github.com/BurntSushi/ripgrep/issues/269 > > in the old past we had some discussion on cmake but finally upstream > accepted our efforts. > Did Cygwin maintain their own set of patchsets for cmake? If so, for how long and for how many version upgrades (until upstream accepted them)? /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
RE: python-cryptography >= 3.4.0 and Rust
> -Original Message- > From: Cygwin-apps > On Behalf Of Marco Atzeri > Sent: Friday, February 4, 2022 1:52 AM > To: cygwin-apps@cygwin.com > Subject: Re: python-cryptography >= 3.4.0 and Rust > > On 03.02.2022 23:11, Allen Hewes wrote: > > Hi @all, > > > > I use Cygwin pretty much like Linux in/on my Windows machines. Meaning, > I am not using it for POSIX reasons. I do like Cygwin a lot, I prefer Cygwin > over > WSL/WSL2. > > > > A PyPI package I wanted to use has a hard dependency on > cryptography>=35.0. > > > > So I downloaded the Cygwin source for python-cryptography and got to > work on updating it to 35.0. > > > > Welp, then the wheels came off. I am assuming that Cygwin's python- > cryptography is still at 3.3.2 b/c of this Rust issue? > > > > Hi Allen, > it is correct. I released the last version that was still on C > It's still on C but the authors have been adding new features in Rust. They are using the Python Rust API bridge for the integration between the two. > > Rust is making more in-roads into software I use frequently or like to use. > > Is > there any efforts or discussions about getting Rust able to target Cygwin? > > Not that I aware of. > We have already problem to update clang that is already behind. > Many of the shiny new sysadmin/sysutils are written in Rust or Go. The reason why I brought up python cryptography and Cygwin is that the current version of python cryptography doesn't support OpenSSL 3 (AFAIK). Only the most recent cryptography does. At some point in the future, this will have to be addressed, wouldn't it (IMHO)? Python cryptography is fundamental in the Python ecosystem. Pythonistas who use Cygwin will need an update to cryptography. How can this happen? > Rust and Go are purely wish, they both requires specific expertize and time. > ...except for then those languages make in-roads into the bits/ecosystem that Cygwin has packaged/supported (for a long time in some cases). From what I can tell, these ecosystems think WSL/WSL2 is their "best effort" for Linux-y (or POSIX) on Windows. > Feel free to work on it Based on the conversation in rigrep (a Rust grepper), it sounds like it's a large amount of work that would not be accepted/entertained by upstream: https://github.com/BurntSushi/ripgrep/issues/269 /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
python-cryptography >= 3.4.0 and Rust
Hi @all, I use Cygwin pretty much like Linux in/on my Windows machines. Meaning, I am not using it for POSIX reasons. I do like Cygwin a lot, I prefer Cygwin over WSL/WSL2. A PyPI package I wanted to use has a hard dependency on cryptography>=35.0. So I downloaded the Cygwin source for python-cryptography and got to work on updating it to 35.0. Welp, then the wheels came off. I am assuming that Cygwin's python-cryptography is still at 3.3.2 b/c of this Rust issue? Cryptography as of 3.4.0 requires Rust when building from source (to make a wheel): https://cryptography.io/en/3.4/changelog.html#v3-4 Cryptography is using PyO3 and it doesn't support Cygwin targets: https://github.com/PyO3/pyo3/issues/1082#issuecomment-683391529 After looking at this more, Rust doesn't support Cygwin targets: https://rust-lang.github.io/rustup/installation/other.html To get updates to Python cryptography, a Rust that can target Cygwin is needed. There is also a swirl of other dependencies below this layer that could cause issues in Cygwin land, e.g. OpenSSL. There's been some efforts and detailed discussions around the edges w.r.t Cygwin and Rust, but it appears that Rust treats Cygwin as a build environment only (like MinGW and friends) and not a native target. Rust is making more in-roads into software I use frequently or like to use. Is there any efforts or discussions about getting Rust able to target Cygwin? Thanks, /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
RE: calm 20210110-1 Python KeyError: 'python-virtualenv'
> mksetupini --arch=x86_64 --inifile=/var/www/custom-
> cygwin/x86_64/setup.ini --disable-check=missing-required-package,missing-
> depended-package,missing-curr --okmissing=required-package --
> releasearea=/var/www/custom-cygwin;
> Traceback (most recent call last):
> File "/usr/local/bin/mksetupini", line 33, in
> sys.exit(load_entry_point('calm==20210110', 'console_scripts',
> 'mksetupini')())
> File "/usr/local/lib/python3.8/site-packages/calm/mksetupini.py", line 170,
> in main
> return do_main(args)
> File "/usr/local/lib/python3.8/site-packages/calm/mksetupini.py", line 51,
> in
> do_main
> packages = package.read_packages(args.rel_area, args.arch)
> File "/usr/local/lib/python3.8/site-packages/calm/package.py", line 117, in
> read_packages
> read_package_dir(packages[root], rel_area, dirpath, files)
> File "/usr/local/lib/python3.8/site-packages/calm/package.py", line 248, in
> read_package_dir
> result = read_one_package(packages, p, relpath, dirpath, fl[kind] +
> fl['all'],
> remove, kind) or result
> File "/usr/local/lib/python3.8/site-packages/calm/package.py", line 283, in
> read_one_package
> (relpath, packages[p].pkgpath))
> KeyError: 'python-virtualenv'
>
> I will revert back to the previous calm, but any ideas?
>
I found it. I got an extra / or a directory in my cp -r command when copying
the cygport packages to my local custom repo and didn't realize it.
New calm works fine.
Sorry for the noise.
/allen
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or
documents linked to this email, are intended for the addressee and may contain
information that is privileged, confidential, proprietary, or otherwise
protected by law. Any dissemination, distribution, or copying is prohibited.
This notice serves as a confidentiality marking for the purpose of any
confidentiality or nondisclosure agreement. If you have received this
communication in error, please contact the original sender.
calm 20210110-1 Python KeyError: 'python-virtualenv'
Hi,
I got the calm 20210110-1 update. It didn't drag in the ztarfile dependency
when setup updated it. So I installed it via pip.
I am now getting Python KeyErrors when I run mksetupini:
mksetupini --arch=x86_64 --inifile=/var/www/custom-cygwin/x86_64/setup.ini
--disable-check=missing-required-package,missing-depended-package,missing-curr
--okmissing=required-package --releasearea=/var/www/custom-cygwin;
Traceback (most recent call last):
File "/usr/local/bin/mksetupini", line 33, in
sys.exit(load_entry_point('calm==20210110', 'console_scripts',
'mksetupini')())
File "/usr/local/lib/python3.8/site-packages/calm/mksetupini.py", line 170,
in main
return do_main(args)
File "/usr/local/lib/python3.8/site-packages/calm/mksetupini.py", line 51, in
do_main
packages = package.read_packages(args.rel_area, args.arch)
File "/usr/local/lib/python3.8/site-packages/calm/package.py", line 117, in
read_packages
read_package_dir(packages[root], rel_area, dirpath, files)
File "/usr/local/lib/python3.8/site-packages/calm/package.py", line 248, in
read_package_dir
result = read_one_package(packages, p, relpath, dirpath, fl[kind] +
fl['all'], remove, kind) or result
File "/usr/local/lib/python3.8/site-packages/calm/package.py", line 283, in
read_one_package
(relpath, packages[p].pkgpath))
KeyError: 'python-virtualenv'
I will revert back to the previous calm, but any ideas?
Thanks,
/allen
Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or
documents linked to this email, are intended for the addressee and may contain
information that is privileged, confidential, proprietary, or otherwise
protected by law. Any dissemination, distribution, or copying is prohibited.
This notice serves as a confidentiality marking for the purpose of any
confidentiality or nondisclosure agreement. If you have received this
communication in error, please contact the original sender.
