11 ms·

> However, rather than use the native toolchains directly, such as Xcode for macOS, we delegated the creation of platform-compliant binaries to py2exe for Windo

> However, rather than use the native toolchains directly, such as Xcode for macOS, we delegated the creation of platform-compliant binaries to py2exe for Windows, py2app for macOS, and bbfreeze for Linux. I wish the authors of more Python tools would deploy standalone applications. I do not like having to maintain various sets of Python installers/package managers (because every Python tool seems to use a different installer). Especially on cloud servers that often lack a whole set of dependencies that Python developers just seem to take for granted. I’m not a Python developer. I don’t have the time or the inclination to repackage various tools and untangle dependencies. Given the choice between trying to figure out how to get multiple Python tools to behave together, or using another tool, I’ll almost always choose an alternative.

cjhanks 8y ago
This is possible and actually pretty trivial. You install all 3rd party dependencies into some directory. The command line entry point is then a simple BASH script which sets the PYTHONPATH to the appropriate installation location and then does the appropriate exec call. You then have a functionally portable python installation.
- rtpg 8y ago
  in the ideal, those making the tools would provide this packaging, instead of asking all users to have `pip` properly set up. Similar issues exist w/r/t npm in my opinion.
- orf 8y ago
  Isn't this just a hacky virtualenv? 'python3 -mvenv dir && ./dir/bin/pip install requirements'?
  - jofer 8y ago
    There are a lot of minor differences, but the biggest difference is that you're able to be completely independent of the system python install. You bundle a complete python interpreter, all libraries needed, etc. The user doesn't need to have python installed at all, and if they have 2.x instead of 3.x or 3.3 when you're expecting features that are only present in >= 3.5, it's no issue. This may sound trivial, but it's a _huge_ deal, particularly when you need to deploy something that runs on multiple different OSes and versions of OSes. Other than that, the "directory full of libs, binaries, and code" approach is a lot easier to package into something that will work well with the native package manager (e.g. an .msi for windows, etc).
- lugg 8y ago
  Pretty trivial? Really? I think as soon as you start writing all caps trivial has gone right out the window. Trivial would be application dependencies managed by the system package manager. I'm at the point where I won't touch a python app or library that can't be installed via Pacman. It's just not worth my time. And... python is still the only thing on arch that gives me the shits everytime it upgrades.
  - throwawaymath 8y ago
    This exchange is a good demonstration that the word "trivial" has lost its meaning in the same way "literal" has. Much like I usually hear someone use term "literally" for figurative emphasis, these days I mostly hear the word "trivial" used to describe something which is clearly nontrivial. Math textbooks have been doing this for decades, but it's leaked into common parlance with online discussion.
    - ezequiel-garzon 8y ago
      I believe in the mathematical community the potentially offensive term for outsiders is non-trivial, used in a technically correct manner, but oftentimes applied as synonymous of epically hard, which unexpectedly throws people off, especially the author of that non-trivial work!
    - CogitoCogito 8y ago
      I think the best translation of "trivial" when used amongst mathematicians is that it is something you should be able to figure out with your current knowledge without too much difficulty (though it might require an hour of thought). Said in another way, you don't need to learn/develop new tools or techniques for something that is trivial. Of course this is not when most people think when they hear the word so really it's a term of art that should probably be avoided when talking to non-mathematicians.
      - Ntrails 8y ago
        > I think the best translation of "trivial" when used amongst mathematicians is that it is something you should be able to figure out with your current knowledge without too much difficulty As i read through my old uni maths notes there are often wild leaps from a to e along with a little scrawl saying "trivially" or "obviously". They may have been true once, but god dammit 21 year old me was a knobber
kccqzy 8y ago
Even when I am a python developer, there is still a difference between (a) this dependency that I explicitly rely on and that I need to sort out packaging issues for, and (b) code I treat as a black box and simply expect to work. More often than not, a typical developer's python environment tends towards https://xkcd.com/1987/ https://xkcd.com/1987/
- weberc2 8y ago
  That xkcd is missing virtualenv, pyenv, pipenv, venv, and poetry.
oweiler 8y ago
That's why most of the tools I use in my day to day work are Go or Rust binaries.
- carlmr 8y ago
  They're also fast and small, which while not always a big matter is very satisfying for me.
  - weberc2 8y ago
    I work in a Python shop. The Docker images we build are nearly 1 GB. I just built a Go service whose image is only 2.5MB. Admittedly it’s much simpler than the Python apps, but even a complex Go app would never reach the size of our Python app for a number of reasons: 1. Python apps require a distro base image while Go can run on scratch 2. Python images ship with the full standard library; not just the bits you import 3. In Python, if you add a dependency only to use 1 function or variable, you still end up with the whole dependency in your Docker image, while I’m pretty sure Go’s linker strips unused code.
    - carlmr 8y ago
      I agree, I'm not a python fan. Python has a few good libraries I can't find in other languages, but it's slow, bad for multi core utilization, hard to distribute, is very wasteful with how many dependencies need to be included, has a terrible package manager and I prefer static strong typing.
      - icebraining 8y ago
        Have you tried mypy? It's a pretty good static typing system for Python - arguably better than Go's.
        weberc2 8y ago
        TL;DR - I continue to root for Python's typing story, but it's just not there yet. I have, and I wanted to like it. On its face it seems like it should be a lot better than Go's--after all, it supports generics and union types! But it falls over in trivial cases, like recursive types (i.e., there's no way to model tree structures such as JSON or linked lists). A few other hard/impossible/confusing things come to mind: 1. How do you declare a typevar for a certain scope. If I define a type parameter `T` for function `foo`, I only want `T` to be scoped to `foo`. I don't want the type checker getting confused with `T`s for other functions/classes/etc. 2. What is the signature for a function that takes args/kwargs? 3. It straight up doesn't work with popular libraries like SQLAlchemy (last I checked, these were simply not supported because the likes of SQLAlchemy are "too magical"--this is a fair take, but frustratingly limiting for users). These are just a few because my memory is poor, but I run into these sorts of things by the dozens every time I try to use mypy. It's just not ready for prime time. Go's type system is limiting, but its limitations are much more predictable and even less limiting (it turns out recursive types and poor-man's union types are quite a bit better than first-class, non-recursive union types, for example).
Rotareti 8y ago
I hope some day some big corp decides to write a decent (open source) Python to C compiler, which makes optional optimizations based on type annotations. I find this project: https://github.com/Nuitka/Nuitka https://github.com/Nuitka/Nuitka very interesting, but its written and maintained only by a single person and I never got it to work with any of my apps.
- fabioz 8y ago
  Cython is a pretty good Python to C compiler and in its latest release is using type annotations... the thing is, you shouldn't need to compile your whole program (compiling is really slow and interpreted Python is fast enough for most of the code).
  - goerz 8y ago
    I was under the impression that Cython is a different language (a subset / dialect of Python). So, not a Python to C compiler.
kartickv 8y ago
Good point. I never understood why the developers of every language don't make it trivial to build a .exe or .app file that users can double-click to run. Seems like the Python team is penalising developers for using Python :) It can internally use an interpreter, JIT, bytecode or full native code like C. That's a different discussion. Just don't make it a pain to distribute.

cjhanks 8y ago

This is possible and actually pretty trivial. You install all 3rd party dependencies into some directory. The command line entry point is then a simple BASH script which sets the PYTHONPATH to the appropriate installation location and then does the appropriate exec call. You then have a functionally portable python installation.

rtpg 8y ago
in the ideal, those making the tools would provide this packaging, instead of asking all users to have `pip` properly set up. Similar issues exist w/r/t npm in my opinion.
orf 8y ago
Isn't this just a hacky virtualenv? 'python3 -mvenv dir && ./dir/bin/pip install requirements'?
- jofer 8y ago
  There are a lot of minor differences, but the biggest difference is that you're able to be completely independent of the system python install. You bundle a complete python interpreter, all libraries needed, etc. The user doesn't need to have python installed at all, and if they have 2.x instead of 3.x or 3.3 when you're expecting features that are only present in >= 3.5, it's no issue. This may sound trivial, but it's a _huge_ deal, particularly when you need to deploy something that runs on multiple different OSes and versions of OSes. Other than that, the "directory full of libs, binaries, and code" approach is a lot easier to package into something that will work well with the native package manager (e.g. an .msi for windows, etc).
lugg 8y ago
Pretty trivial? Really? I think as soon as you start writing all caps trivial has gone right out the window. Trivial would be application dependencies managed by the system package manager. I'm at the point where I won't touch a python app or library that can't be installed via Pacman. It's just not worth my time. And... python is still the only thing on arch that gives me the shits everytime it upgrades.
- throwawaymath 8y ago
  This exchange is a good demonstration that the word "trivial" has lost its meaning in the same way "literal" has. Much like I usually hear someone use term "literally" for figurative emphasis, these days I mostly hear the word "trivial" used to describe something which is clearly nontrivial. Math textbooks have been doing this for decades, but it's leaked into common parlance with online discussion.
  - ezequiel-garzon 8y ago
    I believe in the mathematical community the potentially offensive term for outsiders is non-trivial, used in a technically correct manner, but oftentimes applied as synonymous of epically hard, which unexpectedly throws people off, especially the author of that non-trivial work!
  - CogitoCogito 8y ago
    I think the best translation of "trivial" when used amongst mathematicians is that it is something you should be able to figure out with your current knowledge without too much difficulty (though it might require an hour of thought). Said in another way, you don't need to learn/develop new tools or techniques for something that is trivial. Of course this is not when most people think when they hear the word so really it's a term of art that should probably be avoided when talking to non-mathematicians.
    - Ntrails 8y ago
      > I think the best translation of "trivial" when used amongst mathematicians is that it is something you should be able to figure out with your current knowledge without too much difficulty As i read through my old uni maths notes there are often wild leaps from a to e along with a little scrawl saying "trivially" or "obviously". They may have been true once, but god dammit 21 year old me was a knobber

kccqzy 8y ago

Even when I am a python developer, there is still a difference between (a) this dependency that I explicitly rely on and that I need to sort out packaging issues for, and (b) code I treat as a black box and simply expect to work. More often than not, a typical developer's python environment tends towards https://xkcd.com/1987/ https://xkcd.com/1987/

weberc2 8y ago
That xkcd is missing virtualenv, pyenv, pipenv, venv, and poetry.

oweiler 8y ago

That's why most of the tools I use in my day to day work are Go or Rust binaries.

carlmr 8y ago
They're also fast and small, which while not always a big matter is very satisfying for me.
- weberc2 8y ago
  I work in a Python shop. The Docker images we build are nearly 1 GB. I just built a Go service whose image is only 2.5MB. Admittedly it’s much simpler than the Python apps, but even a complex Go app would never reach the size of our Python app for a number of reasons: 1. Python apps require a distro base image while Go can run on scratch 2. Python images ship with the full standard library; not just the bits you import 3. In Python, if you add a dependency only to use 1 function or variable, you still end up with the whole dependency in your Docker image, while I’m pretty sure Go’s linker strips unused code.
  - carlmr 8y ago
    I agree, I'm not a python fan. Python has a few good libraries I can't find in other languages, but it's slow, bad for multi core utilization, hard to distribute, is very wasteful with how many dependencies need to be included, has a terrible package manager and I prefer static strong typing.
    - icebraining 8y ago
      Have you tried mypy? It's a pretty good static typing system for Python - arguably better than Go's.
      - weberc2 8y ago
        TL;DR - I continue to root for Python's typing story, but it's just not there yet. I have, and I wanted to like it. On its face it seems like it should be a lot better than Go's--after all, it supports generics and union types! But it falls over in trivial cases, like recursive types (i.e., there's no way to model tree structures such as JSON or linked lists). A few other hard/impossible/confusing things come to mind: 1. How do you declare a typevar for a certain scope. If I define a type parameter `T` for function `foo`, I only want `T` to be scoped to `foo`. I don't want the type checker getting confused with `T`s for other functions/classes/etc. 2. What is the signature for a function that takes args/kwargs? 3. It straight up doesn't work with popular libraries like SQLAlchemy (last I checked, these were simply not supported because the likes of SQLAlchemy are "too magical"--this is a fair take, but frustratingly limiting for users). These are just a few because my memory is poor, but I run into these sorts of things by the dozens every time I try to use mypy. It's just not ready for prime time. Go's type system is limiting, but its limitations are much more predictable and even less limiting (it turns out recursive types and poor-man's union types are quite a bit better than first-class, non-recursive union types, for example).

Rotareti 8y ago

I hope some day some big corp decides to write a decent (open source) Python to C compiler, which makes optional optimizations based on type annotations. I find this project: https://github.com/Nuitka/Nuitka https://github.com/Nuitka/Nuitka very interesting, but its written and maintained only by a single person and I never got it to work with any of my apps.

fabioz 8y ago
Cython is a pretty good Python to C compiler and in its latest release is using type annotations... the thing is, you shouldn't need to compile your whole program (compiling is really slow and interpreted Python is fast enough for most of the code).
- goerz 8y ago
  I was under the impression that Cython is a different language (a subset / dialect of Python). So, not a Python to C compiler.

kartickv 8y ago

Good point. I never understood why the developers of every language don't make it trivial to build a .exe or .app file that users can double-click to run. Seems like the Python team is penalising developers for using Python :) It can internally use an interpreter, JIT, bytecode or full native code like C. That's a different discussion. Just don't make it a pain to distribute.