3 ms·
This is almost identical to how bundler in Ruby works, right down to the language native dependency DSL, named groups, file name conventions (Pipfile = Gemfile,
by examancer 10y ago
This is almost identical to how bundler in Ruby works, right down to the language native dependency DSL, named groups, file name conventions (Pipfile = Gemfile, Pipfile.lock = Gemfile.lock), and deterministic builds.
It's identical because bundler mostly got it right and dependency management in Ruby, while still not great/perfet, is better than just about everywhere else.
Kudos to python for moving forward.
- INTPenis 10y agoWow I'm amazed at how skewed my world view was. The first two comments I read are praising ruby dependency management and scorning pythons requirements. I'm sitting here thinking, "what the hell is wrong?". I've honestly only experienced trouble with Ruby while being completely satisified with how python virtualenv works. I guess if anything this proves that it's about habit. Habitual use of something makes it the easiest product for the habitual user. Ruby is something I force myself through when I want to try a product while Python is something I develop my own products in.
- examancer 10y agoI used to think PHP was amazing and build tools were weird and unnecessary when I built things mostly in PHP. It's hard to see the point of many tools if you aren't working with the all the time. I think this is the product of people who got to know both Python and Ruby very well and found Python lacking here. There are lots of things Ruby developers were gifted from people who also know Python and found Ruby lacking. Python is generally something I force myself through so I'm not one of those people but so glad they exist. BTW, Ruby has tools similar to virtualenv: chruby, rbenv, and rvm all do basically the same thing.
- mypalmike 10y agoMy experience has been quite the opposite wrt ruby and python. I spent 2 years with Ruby as my primary language, and the regularity in which I would end up with a subtly (or drastically) broken Ruby environment was astounding. With python, I've rarely if ever run into such problems.
- regularfry 10y agoThe problem in Ruby that the most frequently recommended tools are overcomplicated and break in horrible ways (but I repeat myself). You only need to set a couple of environment variables to define a working Ruby environment. I regularly have people ask me "do you use rvm or rbenv?" to be surprised when I say "neither, they're both horrible."
- INTPenis 10y agoI think the sore point is definitely build and packaging systems. Take zulip for example, they do use requirements but they go their own way in most other things. Managing an application is much easier if it uses standard build system. Setup.py, requirements.txt and so forth. Gitlab is an example of a very complex packaging for a ruby application, but it works! It's complex but solid. People are tugging in all kinds of different directions. My bad experiences with Ruby and node usually include seeing a loooong list of dependencies being installed and then at dependency #187 it suddenly stops for some reason like one rogue commit breaking compatibility with other packages. This is hell to someone who doesn't develop in the language regularly, it's a bad packaging system for users. To be clear, I'm not saying Python is better. I'm just identifying the issues I've had. The only reason Python is easier for me is because I've decided to use it more than the other languages. On the one hand you can build a complex but solid system like Gitlab has, on the other you can use more standardized systems to distribute your app that require more steps and are less automated. But they're well documented and established methods used for that language.
- pfranz 10y agoMy background is in Python, too. There was a summer where I dug into Ruby and Rails and I was really impressed with a lot of the concepts. I had dabbled with Flask and Django, but I things like the Gem lockfile, switching easily between test, dev, and production database, and database versioning (at least with little setup) solved problems I had when using Python (I'm not a webdev). I tried to pitch the Gemfile and lockfile approach when we were developing our own internal packaging system but nobody seemed to "get it" or see the value. I also tried to pitch database versioning (which alembic seems to do), but again, no takers. I feel like it was a failing on my part to communicate or show the value in these things...they came randomly out of meetings and I probably botched the concept when pitching it. I've stumbled with requirements.txt and setting up a new package. I'm also picky and don't like installing packages to my system (and I'm not always using virtualenv) so I have to look up how to install to my homedir. So I've stumbled with Python packaging (although, I think everyone can admit it has a bit of a hodgepodge) while I liked how Ruby did it.