dh-virtualenv
py2app
dh-virtualenv | py2app | |
---|---|---|
4 | - | |
1,603 | - | |
0.1% | - | |
0.0 | - | |
about 2 months ago | about 8 years ago | |
Python | ||
GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
dh-virtualenv
-
PyPi root metapackage?
This is how Azure package functions, iirc. I think I used this https://github.com/spotify/dh-virtualenv for similar purpose some time ago.
-
What to do about GPU packages on PyPI?
I'm in a devops role where we actually reroll the Tensorflow whl in-house (to get a few tweaks like specific AVX flags turned on), but because the rest of our deployment is apt/debs, we then turn around and wrap that whl in a deb using Spotify's excellent dh-virtualenv:
https://github.com/spotify/dh-virtualenv
There's no expertise for Bazel in-house; when we run the build, it seems to fail all its cache hits and then spend 12-13h in total compiling, much of which appears to be recompiling a specific version of LLVM.
Every dependency is either vendored or pinned, including some critical things that have no ABI guarantees like Eigen, which is literally pinned to some a random commit, so that causes chaos when other binaries try to link up with the underlying Tensorflow shared objects:
https://github.com/tensorflow/tensorflow/blob/master/third_p...
And when you go down a layer into CUDA, there are even more support matrixes listing exact known sets of versions of things that work together:
https://docs.nvidia.com/deeplearning/tensorrt/support-matrix...
Anyway, I'm mostly just venting here. But the whole thing is an absurd nightmare. I have no idea how a normal distro would even begin to approach the task of unvendoring this stuff and shipping a set of normal packages for it all.
-
Working with Rust in VSCode’s devcontainer: Seamlessly run your Rust programs under a development container in Visual Studio Code.
Rarely do I develop software at my host level, I'm almost always doing it inside of a container or a virtual machine (local or remote), and part of that is simple muscle memory to solve several problems that you've mentioned in your experience with Python, as well as other languages (bonus points for me that I was never plagued by a horrid npm bug). Those are problems that are easily solvable with Docker and a properly formatted requirements.txt (which should only be used in development — use pip/setup.py for proper deployment) and for the rare times when I do need to use Python at the host level of a Linux system, I use Spotify's dh-virtualenv.
-
Is there an excellent Python equivalent for glitch.com?
Maybe I misunderstood the question, but this would be the point of CI/CD and containerization as far as industry standards are concerned. If you had to deploy at host level, then this would be the point of dh-virtualenv that’s tied in by your CI/CD system.
py2app
We haven't tracked posts mentioning py2app yet.
Tracking mentions began in Dec 2020.
What are some alternatives?
PyInstaller - Freeze (package) Python programs into stand-alone executables
Nuitka - Nuitka is a Python compiler written in Python. It's fully compatible with Python 2.6, 2.7, 3.4-3.12. You feed it your Python app, it does a lot of clever things, and spits out an executable or extension module.
PyOxidizer - A modern Python application packaging and distribution tool
pyarmor - A tool used to obfuscate python scripts, bind obfuscated scripts to fixed machine or expire obfuscated scripts.
pynsist - Build Windows installers for Python applications
py2exe - modified py2exe to support unicode paths
packaging - Core utilities for Python packages