4 ms·

py2pp for the Mac. It appears there is a py2deb and py2rpm for Linux, and I imagine users of Arch, Slack, etc. would be expected to download a .tgz and `setup.p

py2pp for the Mac. It appears there is a py2deb and py2rpm for Linux, and I imagine users of Arch, Slack, etc. would be expected to download a .tgz and `setup.py install` it.

ginko 13y ago
> I imagine users of Arch, Slack, etc. would be expected to download a .tgz and `setup.py install` it. In Arch you would wrap this in a PKGBUILD script to generate a Pacman package. You can find PKGBUILD's for most things in the AUR.
- oinksoft 13y ago
  Ah, of course, you would want to create a slackpkg for Slack, and push to the AUR for Arch. It's still good to offer the .tgz as a baseline for users of systems you might have forgotten or not have time to package for though, (BSD, etc.).
st3fan 13y ago
Yeah py2deb or py2rpm are great. Now do the same for all your dependencies. And their dependencies. And their dependencies. And their ... Single artifact does not mean 'your code'. It means 'the whole damn project including all dependencies recursively'. Think myapp-1.0.war that contains all dependent JAR files. Drop it in a container and it runs. Or your Go compiled tool that is one single static executable that has no reference to external code or libraries. Run it and it works. I know how I can package my own Python code. I am not too worried about that. I am however really tired of packaging the whole thing every time. And then dealing with stupid things like python packages that need a C compiler to build. Or specific patches to dependent C libraries. Or specific versions of things that some distro might not have. Or dependencies for which I need a newer version than the OS provides. Or .. sigh .. there are so many stupid gotchas that are complete time wasters to deal with.
- oinksoft 13y ago
  I'm not advocating either tool, just answering his question.
- Goladus 13y ago
  The main thing you need to understand is that "source code" vs. "single deployable artifact" are impossible to evaluate without considering platform requirements. Source code is very compatible across many architectures and operating systems but needs compilation, configuration, and dependencies. Binaries are highly compatible with a single platform and work out of the box. However they are not very compatible with any other platform. The downside is that if you want any feature not provided by the JVM's abstraction layer, at the very least you are in the exact same boat as a python developer.

py2pp for the Mac. It appears there is a py2deb and py2rpm for Linux, and I imagine users of Arch, Slack, etc. would be expected to download a .tgz and `setup.py install` it.

ginko 13y ago

> I imagine users of Arch, Slack, etc. would be expected to download a .tgz and `setup.py install` it. In Arch you would wrap this in a PKGBUILD script to generate a Pacman package. You can find PKGBUILD's for most things in the AUR.

oinksoft 13y ago
Ah, of course, you would want to create a slackpkg for Slack, and push to the AUR for Arch. It's still good to offer the .tgz as a baseline for users of systems you might have forgotten or not have time to package for though, (BSD, etc.).

st3fan 13y ago

Yeah py2deb or py2rpm are great. Now do the same for all your dependencies. And their dependencies. And their dependencies. And their ... Single artifact does not mean 'your code'. It means 'the whole damn project including all dependencies recursively'. Think myapp-1.0.war that contains all dependent JAR files. Drop it in a container and it runs. Or your Go compiled tool that is one single static executable that has no reference to external code or libraries. Run it and it works. I know how I can package my own Python code. I am not too worried about that. I am however really tired of packaging the whole thing every time. And then dealing with stupid things like python packages that need a C compiler to build. Or specific patches to dependent C libraries. Or specific versions of things that some distro might not have. Or dependencies for which I need a newer version than the OS provides. Or .. sigh .. there are so many stupid gotchas that are complete time wasters to deal with.

oinksoft 13y ago
I'm not advocating either tool, just answering his question.
Goladus 13y ago
The main thing you need to understand is that "source code" vs. "single deployable artifact" are impossible to evaluate without considering platform requirements. Source code is very compatible across many architectures and operating systems but needs compilation, configuration, and dependencies. Binaries are highly compatible with a single platform and work out of the box. However they are not very compatible with any other platform. The downside is that if you want any feature not provided by the JVM's abstraction layer, at the very least you are in the exact same boat as a python developer.