5 ms·

On the python side, this matches my experiences with python. Python is a great language, and I like it very, very much. However, packaging and deployment in pyt

by tetha 11y ago

On the python side, this matches my experiences with python. Python is a great language, and I like it very, very much. However, packaging and deployment in python remains such an amazing mess, even after 20 years. And outside of scientific computing, python doesn't offer any real edge, to me at least. Ruby has better tooling libraries, java/go/c++ have better performance, JS has more powerful website frameworks. Why should I bother with that packaging mess after having it done once already?

ynezz 11y ago
> packaging and deployment in python remains such an amazing mess, even after 20 years. I'm Lua fanboy, but I've to admit, that I'm missing clean deployments and upgrades with virtualenv and pypi available in Pyhton. I've never had any issue so far, am I being just lucky bastard? It has been like that for many years already. > Ruby has better tooling libraries On the other hand, I've honest to maintain one Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance :-)
- SeanDav 11y ago
  > "....Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance...." Well that is your problem right there - don't drink in advance, drink afterwards to try delete the traumatic experience from your memory!
- x0x0 11y ago
  those handle python deps ok, but not lib dependencies, at least last time I was forced to use it. If your company has a mix of older and newer projects, you'll end up with eg conflicting dependencies on libxml. My solution was to docker all the things. It made my life so much better; you could simultaneously run multiple services on the same box without awful fragile hacks.
  - brimworks 11y ago
    Docker is a great tool, but not all customers will have that available to them, and the docker experience isn't great for customers on Windows/Mac since they have to run Linux in a VM, which means the agent would have the footprint of an entire OS on those platforms.
  - icebraining 11y ago
    You can bundle libxml.so and such and load it from your directory. Docker is certainly an option, but it's like using a sledgehammer to crack a nut.
- tetha 11y ago
  > I'm Lua fanboy, but I've to admit, that I'm missing clean deployments and upgrades with virtualenv and pypi available in Pyhton. I've never had any issue so far, am I being just lucky bastard? It has been like that for many years already. There's a few python libraries out there which just crash the entire stack, like Python-Mysql (or was it PyMysql, or one of the other very similarly named libraries?). And I might be biased, but talking to a mysql-db shouldn't be hard. >On the other hand, I've honest to maintain one Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance :-) I rather mean tools like rake as a task-runner, guard, rubocop, thor as a templating system, rspec, chef as config management, kitchen, food-critic, sinatra for easy web services. It's a whole bunch of stable tools and tooling libraries (and they are integrating with each other).
- garrid0r 11y ago
  Completely off topic: if you're running your Redmine instance for work, try to convince your boss to give it to Planio. They charge a fraction of what you're costing them and they really know their shit. I had to maintain redmine(s) at my current company and it just feels so awesome since we outsourced. They do all the updates and backups, we can request plugin installations, etc. amazing support, too. I can't stop raving about them, seriously. I think they're from Europe and their devs are all Redmine contributors. https://plan.io/redmine-hosting/ https://plan.io/redmine-hosting/ They also have a program where they move your data for free: https://plan.io/data-import-and-migration/ https://plan.io/data-import-and-migration/
stcredzero 11y ago
Python is a great language, and I like it very, very much. However, packaging and deployment in python remains such an amazing mess When are dynamic languages finally going to learn from these problems and fix them? Smalltalkers were making these exact complaints to me in person in the 90's and I know they predated my involvement by a lot. What if someone created a Smalltalk-like uber-debugging-godlike-power-over-the-runtime alternative compiler target for Golang? Then you'd have all the good parts of dynamic languages with the dead-simple distribution model of Golang.
- monkmartinez 11y ago
  I have recently installed Go on my machine. Then I made a quick little server and put it on Digital Ocean. It was seriously the easiest thing I've done with "shipping" code in a long time. I love Python, it is my hammer and everything looks like a nail. However, Go makes it so easy to share/deploy all the things. I could see Go becoming my hammer.
  - ambulancechaser 11y ago
    i played with it last week but decided to play around with Rust instead since there was no debugger support and the official statement from the go team was that they have no intention of making integrations with gdb
    - reality_czech 11y ago
      The problem with Go is that it only works in practice, not in theory.
  - devishard 11y ago
    Have you tried writing "a quick little server" in Python and deploying it? Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems. With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go. You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option. I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries. If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight.

by tetha 11y ago

ynezz 11y ago

> packaging and deployment in python remains such an amazing mess, even after 20 years. I'm Lua fanboy, but I've to admit, that I'm missing clean deployments and upgrades with virtualenv and pypi available in Pyhton. I've never had any issue so far, am I being just lucky bastard? It has been like that for many years already. > Ruby has better tooling libraries On the other hand, I've honest to maintain one Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance :-)

SeanDav 11y ago
> "....Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance...." Well that is your problem right there - don't drink in advance, drink afterwards to try delete the traumatic experience from your memory!
x0x0 11y ago
those handle python deps ok, but not lib dependencies, at least last time I was forced to use it. If your company has a mix of older and newer projects, you'll end up with eg conflicting dependencies on libxml. My solution was to docker all the things. It made my life so much better; you could simultaneously run multiple services on the same box without awful fragile hacks.
- brimworks 11y ago
  Docker is a great tool, but not all customers will have that available to them, and the docker experience isn't great for customers on Windows/Mac since they have to run Linux in a VM, which means the agent would have the footprint of an entire OS on those platforms.
- icebraining 11y ago
  You can bundle libxml.so and such and load it from your directory. Docker is certainly an option, but it's like using a sledgehammer to crack a nut.
tetha 11y ago
> I'm Lua fanboy, but I've to admit, that I'm missing clean deployments and upgrades with virtualenv and pypi available in Pyhton. I've never had any issue so far, am I being just lucky bastard? It has been like that for many years already. There's a few python libraries out there which just crash the entire stack, like Python-Mysql (or was it PyMysql, or one of the other very similarly named libraries?). And I might be biased, but talking to a mysql-db shouldn't be hard. >On the other hand, I've honest to maintain one Redmine instance (which is written in Ruby) and this is real nightmare for me. Each time I've to upgrade, I've to drink a lot day or two in advance :-) I rather mean tools like rake as a task-runner, guard, rubocop, thor as a templating system, rspec, chef as config management, kitchen, food-critic, sinatra for easy web services. It's a whole bunch of stable tools and tooling libraries (and they are integrating with each other).
garrid0r 11y ago
Completely off topic: if you're running your Redmine instance for work, try to convince your boss to give it to Planio. They charge a fraction of what you're costing them and they really know their shit. I had to maintain redmine(s) at my current company and it just feels so awesome since we outsourced. They do all the updates and backups, we can request plugin installations, etc. amazing support, too. I can't stop raving about them, seriously. I think they're from Europe and their devs are all Redmine contributors. https://plan.io/redmine-hosting/ https://plan.io/redmine-hosting/ They also have a program where they move your data for free: https://plan.io/data-import-and-migration/ https://plan.io/data-import-and-migration/

stcredzero 11y ago

Python is a great language, and I like it very, very much. However, packaging and deployment in python remains such an amazing mess When are dynamic languages finally going to learn from these problems and fix them? Smalltalkers were making these exact complaints to me in person in the 90's and I know they predated my involvement by a lot. What if someone created a Smalltalk-like uber-debugging-godlike-power-over-the-runtime alternative compiler target for Golang? Then you'd have all the good parts of dynamic languages with the dead-simple distribution model of Golang.

monkmartinez 11y ago
I have recently installed Go on my machine. Then I made a quick little server and put it on Digital Ocean. It was seriously the easiest thing I've done with "shipping" code in a long time. I love Python, it is my hammer and everything looks like a nail. However, Go makes it so easy to share/deploy all the things. I could see Go becoming my hammer.
- ambulancechaser 11y ago
  i played with it last week but decided to play around with Rust instead since there was no debugger support and the official statement from the go team was that they have no intention of making integrations with gdb
  - reality_czech 11y ago
    The problem with Go is that it only works in practice, not in theory.
- devishard 11y ago
  Have you tried writing "a quick little server" in Python and deploying it? Packaging and deployment aren't problems in Go OR Python if you're only solving trivial problems. With a larger project, you might have an easier time packaging and deploying Go code, but that's largely because there are no libraries to package. Admittedly packaging can be a pain in Python, but that's usually because of poor choices in dependencies. Packaging Python with a few mature dependencies isn't hard in my experience. It's the projects where some idiot has pulled in every 0.x versioned library in pip that are hard to package. When Go has as wide a variety of libraries as Python people will run into the same problems in Go. You could argue that at least for now Go doesn't allow you to shoot yourself in the foot that way, but I'd rather have the option. I'm not defending Python in particular here. I'd say the same things I've said here about any mature language with extensive libraries. If you're espousing Go because of easy packaging and deployment, I strongly suggest that you consider whether that's actually a feature Go will have long term, and whether you're currently paying for that feature by having no libraries available to you. The only lesson I would take away from Go's easy packaging is to only use mature dependencies that pull their weight.