4 ms·
A new home for Python-build-standalone
- themusicgod1 2y ago> With those modifications, it then builds Python from source across a wide matrix of Python versions, platforms, and build variants (e.g., optimized vs. debug builds), and publishes the built distributions to GitHub Releases. This should be illegal.
- JackYoustra 2y agoWhy?
- cdchn 2y agoSupply chain risk.
- the_mitsuhiko 2y agoPlease explain your reasoning.
- cdchn 2y agoSomebody else is building your binaries. You've added another link in your software supply chain. How do you know they haven't inserted malware?
- the_mitsuhiko 2y ago> Somebody else is building your binaries. That happens all the time. Who builds the docker images you are using? > You've added another link in your software supply chain. How do you know they haven't inserted malware? You're installing untrusted random packages from PyPI. There are many much weaker points than Astral giving you malware for fun.
- cdchn 2y agoSure it happens, but that doesn't mean you shouldn't think about reducing it.
- maxloh 2y ago> Somebody else is building your binaries. FYI there are two parties you are talking about: Astral, and GitHub too (if you don't trust Microsoft).
- themusicgod1 2y agoPublishing to Github should be considered a crime.
- mistrial9 2y agoHow to handle this situation is literally defined in the LICENSE for any modern software project
- est 2y agoA big thank you to Gregory and the Astral team. The binaries saved me tons of bullshit build time. The saved CPU cycles also helped reducing carbon footprint!
- 0cf8612b2e1e 2y agoThis is a huge relief. I love the uv bootstrapping, but was unhappy with the built-in-Nebraska feel for how they sourced Python. Still not as great as being an official Python.org project, but an excellent step.
- ekzhang 2y agoJust want to mention that these standalone python builds have been super important for simplifying a lot of dev tooling, even if users may not see it directly — I work for a cloud infrastructure company, and they’re what allow us to give users a one-line way of adding Python to any Docker image they desire. It’s helpful to have reproducible, standalone Python builds of this quality (and release transparency). Thanks y’all for taking this on.
- baggiponte 2y agoOh you maintain PyTorch right?
- paulgb 2y agoI think GP is https://www.ekzhang.com/ https://www.ekzhang.com/ (hi Eric!), not http://ezyang.com/ http://ezyang.com/
- figomore 2y agoI think the next project adopted by Astral will be PyOxidizer.
- cdchn 2y agoThat was my thought as well. "Hopefully someone decides to take on the stewardship of PyOxidizer, too." That might not dovetail well enough with someone's business plans though.
- mikkelam 2y agoat this point they should just start their own Python implementation :-)
- james_anderson 2y agoI really hope so
- ameliaquining 2y ago> Normally, when you build CPython on Linux or macOS, several system paths are hardcoded into the binary. This is fine if you're building and installing Python on a single machine, but it's a problem if you want to pre-build Python and then distribute it to other machines. > So, for example, when you download Python on Linux (e.g., from python.org), what you're actually downloading is the CPython source, which is then built on your machine. But python.org does provide prebuilt macOS binaries. How is that accomplished and why doesn't whatever they're doing generalize to Linux?
- ivoflipse 2y agoThis is actively being discussed https://discuss.python.org/t/publish-linux-installer-on-python-org/53760 https://discuss.python.org/t/publish-linux-installer-on-pyth... A big holdup seems to be who would maintain this in the CPython project. Perhaps some Astral folks could become core devs as well and maintain it upstream
- gkeralt 2y agoHardly anyone who does real work would want to contribute to CPython these days. The reputational risk is too high, the work would be taken, modified and slowly ruined by the mediocre influencers. I would advise against Astral for maintaining anything inside the Python organization. Too much talk, power plays and no real software engineering.
- fuzztester 2y ago? Source needed. Pun unintended.
- the_mitsuhiko 2y agoThe parent comment is inflammatory. That said, moving anything in the Python project requires a lot of energy, there is high friction and it's probably not wise to try to do that until something has established itself outside. The discussions around lockfiles, dynamic metadata or PyBI (the PEP that wanted to address what python-build-standalone does) are good examples of how hard it is to cause change in that space.
- antman 2y agoI hope this is also relevant to extending uv towards creating standalone python executables
- NeutralForest 2y agoAmazing, I'm really hoping Astral will stay in the game for long!
- deleted 2y ago[deleted]