public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* python-cryptography >= 3.4.0 and Rust
@ 2022-02-03 22:11 Allen Hewes
  2022-02-04  6:52 ` Marco Atzeri
  0 siblings, 1 reply; 5+ messages in thread
From: Allen Hewes @ 2022-02-03 22:11 UTC (permalink / raw)
  To: cygwin-apps

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: python-cryptography >= 3.4.0 and Rust
  2022-02-03 22:11 python-cryptography >= 3.4.0 and Rust Allen Hewes
@ 2022-02-04  6:52 ` Marco Atzeri
  2022-02-04 15:28   ` Allen Hewes
  0 siblings, 1 reply; 5+ messages in thread
From: Marco Atzeri @ 2022-02-04  6:52 UTC (permalink / raw)
  To: cygwin-apps

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

> 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.

Rust and Go are purely wish, they both requires specific expertize
and time.

Feel free to work on it

> Thanks,
> 
> /allen

Regards
Marco

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: python-cryptography >= 3.4.0 and Rust
  2022-02-04  6:52 ` Marco Atzeri
@ 2022-02-04 15:28   ` Allen Hewes
  2022-02-04 21:28     ` Marco Atzeri
  0 siblings, 1 reply; 5+ messages in thread
From: Allen Hewes @ 2022-02-04 15:28 UTC (permalink / raw)
  To: cygwin-apps

> -----Original Message-----
> From: Cygwin-apps <cygwin-apps-bounces+allen=decisiv.com@cygwin.com>
> 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: python-cryptography >= 3.4.0 and Rust
  2022-02-04 15:28   ` Allen Hewes
@ 2022-02-04 21:28     ` Marco Atzeri
  2022-02-07  4:02       ` Allen Hewes
  0 siblings, 1 reply; 5+ messages in thread
From: Marco Atzeri @ 2022-02-04 21:28 UTC (permalink / raw)
  To: cygwin-apps

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

>>> 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 ...

>> 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.

> /allen
> 

Regards
Marco

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: python-cryptography >= 3.4.0 and Rust
  2022-02-04 21:28     ` Marco Atzeri
@ 2022-02-07  4:02       ` Allen Hewes
  0 siblings, 0 replies; 5+ messages in thread
From: Allen Hewes @ 2022-02-07  4:02 UTC (permalink / raw)
  To: cygwin-apps

> -----Original Message-----
> From: Cygwin-apps <cygwin-apps-bounces+allen=decisiv.com@cygwin.com>
> 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-02-07  4:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-03 22:11 python-cryptography >= 3.4.0 and Rust Allen Hewes
2022-02-04  6:52 ` Marco Atzeri
2022-02-04 15:28   ` Allen Hewes
2022-02-04 21:28     ` Marco Atzeri
2022-02-07  4:02       ` Allen Hewes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).