07:30 <fijal> https://pypi.org/project/encrust/2023.3.17.1/

07:31 <fijal> this is glyph library for signing python stuff for running on OS X, someone might want to investigate if we can make pypy signed

07:54 <glyph> fijal: does pypy build as a framework?

07:58 <fijal> I don't think so?

07:59 <glyph> fijal: so, you can sign pypy as an executable, in the same way that python.org does, but my tool will probably not be very interesting for you

07:59 <fijal> "ah"

07:59 <glyph> you don't have a bundle, so you will need to submit the individual executable file

07:59 <fijal> the problem is a myriad of .so that come with it

07:59 <glyph> you can … probably just ignore those

08:00 <fijal> what do you mean "ignore"? They certainly explode when I try to make an exception

08:00 <fijal> (like I have to click in settings every individual extension module)

08:01 <glyph> the only thing that signing gets you on a CLI tool is that you get to skip this: https://dsc.cloud/6282b4/pb-BiWUhF15R3.png

08:01 <glyph> and you don't need to tell your users to dequarantine the binary

08:01 <fijal> yeah, that would be fantastic

08:01 <fijal> running pypy is a mess, because it does that every time it loads an extension .so

08:01 <glyph> fijal: I could try signing it and see what happens

08:01 <fijal> so not every run is the same (loads the same sos)

08:01 <glyph> hmm

08:01 <glyph> python avoids this somehow

08:01 <fijal> and pip explodes horrendously

08:03 <glyph> aha

08:03 <glyph> com.apple.security.cs.disable-library-validation

08:03 <glyph> looks like you just need to add some entitlements

08:03 <glyph> fijal: can you point me at a binary to sign?

08:04 <glyph> I'll do https://downloads.python.org/pypy/pypy3.9-v7.3.11-macos_arm64.tar.bz2

08:34 <glyph> ugh okay I give up

08:35 <glyph> fijal: apple really wants you to package code in one of a couple of ways, and pypy is none of those ways. CPython comes in a .pkg for this reason, I think, because there's pretty much no way for me to staple a notarization ticket to either the dylib or the executable

08:36 <glyph> I tried submitting the files in a zip and it accepted them but then it apparently did nothing.

08:37 <glyph> even with wildly permissive memory and linking entitlements it still gives me the "library load disallowed by system policy" error at startup

08:38 <glyph> you should probably talk to ned deily about this, he is the one who knows how cpython's magic is set up

08:45 <fijal> glyph: ok, well, I don't think I'm happy to invest in pypy packaging at this stage, thanks though!

08:48 <glyph> fijal: oh hahaha I bet you could fix this with a shell script wrapper

09:04 <glyph> fijal: here; move 'pypy3.9' to 'pypy3.9.real', replace the binary with this https://gist.github.com/glyph/57622df0ee1e452537b4a49f461c7e74

09:04 <glyph> problem solved

09:05 <glyph> maybe some edge cases to debug around virtualenv or something ther

09:05 <glyph> e

09:05 <glyph> but shell scripts don't require signing because /bin/sh is already signed yolooooooooo

09:09 <glyph> alternately, remove the 'download' link on the website for macOS, replace it with a command to copy paste that says `curl -LO https://downloads.python.org/pypy/pypy3.9-v7.3.11-macos_arm64.tar.bz2` - anything downloaded manually at a command-line won't get the quarantine bit set in the first place, and the command will run unperturbed

10:04 <fijal> eh I wish matti saw this

13:38 <tumbleweed> lolwtf

13:38 <tumbleweed> I mean, I understand that they have to start somewhere, but still lol

16:59 <jean-paul[m]> fijal: If you made it possible to develop mobile apps in Python with PyPy then you'd probably get a lot of adoption

16:59 <jean-paul[m]> A lot of Python programs would like to be able to do mobile but practically they have to abandon Python for that right now

17:02 <jean-paul[m]> (I might go on to implore you not to do this, but maybe I won't do it in this channel)

17:03 <tumbleweed> jean-paul[m]: what do you think pypy can provide that they need?

17:03 <tumbleweed> or are you talking about building apps in rpython

17:09 <jean-paul[m]> tumbleweed: A development process that is better than Kivy, either by eliminating the need for third-party extension modules or by providing a build process for them that actually works.

17:09 <jean-paul[m]> (Definitely not RPython, I don't think you'll get any appreciable uptake on an offering for application development in RPython)

17:10 <tumbleweed> phew re rpython :)

17:10 <jean-paul[m]> Kivy is pretty much the most streamlined CPython-for-mobile toolkit and it is not very streamlined and it is built on a huge pile of hacks and it doesn't look like either of those things are going to change any time soon.

17:11 <tumbleweed> you think being able to use more pure-python would allow simplifying things enough to increase adoption?

17:11 <tumbleweed> ah, kivy leans heavily on cython. If I knew that, I'd forgotten

17:20 <jean-paul[m]> tumbleweed: I think that will help but I think PyPy would also need to make building extension modules easier

17:21 <jean-paul[m]> It seems like, in practice, the Python ecosystem has not hailed PyPy as a solution to writing C. There are still lots of extension modules written in C. And now, in Rust too.

17:21 <jean-paul[m]> But that's okay, cross-compiling is a thing. It's just ... not really a thing for CPython.

17:21 <jean-paul[m]> (It is if you are a compilers expert and sink 80 hours into it, but that excludes most developers)

18:03 <tumbleweed> this seems like something that could be resolved with a few build tools