4 ms·
Well you see actually Python packaging is extremely simple, people just don’t get it. You just use pip! Well actually distutils is what you use not pip, except
by hjk05 8y ago
Well you see actually Python packaging is extremely simple, people just don’t get it. You just use pip! Well actually distutils is what you use not pip, except don’t use distutils use setuptools instead, distutils is outdated, but not really because setuptools uses distutils internally... but anyways you should use setuptools is what I mean. Anyway you just set up a setup.py file with all the details of your package, except don’t do that, instead use a minimalistic setup.py and write your metadata in setup.cfg, except that’s silly instead put your version in the module, and your description in a file and use hooks in the setup.cfg to get them. Except actually you should maybe use pipenv instead, or poetry actually or what was it this week again? Err so where were we. Ohh yea, python packaging is really simple, people just don’t get it. But wait we haven’t really touched on virtual environments and dependency management yet....
My favorite vote for “Completely break backwards compatibility in python4” is packaging. Tear it all out in one go and completely forget it then start fresh with one and only one way to do it, under completely new names kill pip, setup.py and everything connected to them and let the Phoenix rise again under a new name. Google is a graveyard of the last 6 different “the new way of doing it” and everyone learns by doing it “wrong” 3-4 different ways before they get even close to what’s considered “the right way” this quarter... and then they bikeshed their own “fix” over that and share it on their blog to confuse everyone else. It’s frustrating to no end.
All that and we havn’t even touched on distributing projects that mix in c++/c, or just pure python projects that need to be compiled to an executable pyinstaller works great for that though! Until it doesn’t for some obscure unknown reason you’ll then have to figure out.
Building c++ projects is an absolute breeze compared to the hell that is Python.
- mercer 8y agoI went from Ruby, to Node, to Elixir, and my annoyances with the package/project managers have decreased with every step. I'm honestly surprised that Python's 'approach' is so much worse than any of them. Are there any particular reason why there hasn't been a good package/project manager that became dominant in the Python ecosystem? To elaborate on my current situation. With Elixir, I run mix new <project-name> and I get 1) a project structure, including test helpers, config stubs, formatter config, gitignore, and a mix.ex file where I can add dependencies. With some flags, I can get a supervised setup (for long-running stuff, basically), or an umbrella app that allows me to put multiple projects under one 'umbrella project'. Aside from potential issues where the apps in an umbrella rely on different version of the same package, dependency is local to the project and doesn't conflict with another. I also get formatting and test 'tasks', with DocTest support.