3 ms·

Couple of points/expansions >if you are in linux, research how to install python seriously. I.e, build from source, after installing necessary dependencies (h

Couple of points/expansions >if you are in linux, research how to install python seriously. I.e, build from source, after installing necessary dependencies (https://devguide.python.org/getting-started/setup-building/#build-dependencies https://devguide.python.org/getting-started/setup-building/#...). Use sudo make altinstall to install the specific version. Usually distro provided ones are pretty old anyways, so you want the faster 3.11 and on. >Never do something outside of a venv. Not even install black. You can get very far with just that. If you want to just write scripts to test things, working outside venv is fine as long as you manually install pip using get-pip.py, then invoke pip using python3.xx -m pip (make a bash alias for this command, and then delete the binaries in ~/.local/bin). This will install all the binaries to ~/.local/lib/python3.xx/site-packages, which keeps everything isolated. >if you want to have better tooling, use pip-tools. Not pipenv. Not poetry. Not anything else. Also, stick to setup.py for module installation definition. It keeps everything in one place and allows you to run custom workflows. For example, if you wanna run flake8 on install to check your code, with pyproject.toml, it requires pyproject.toml and setup.cfg. With setup.py, you can do this all in one file. Not only that, it gives you extra options to run certain commands. >if you want to build a package, use hatch. setuptools is fine for building a wheel - all you are doing is moving files around and zipping them. As far as OS goes, if you are on Windows, use WSL2 and run python there. Don't even bother with Windows python. If you are on mac, use `asdf` for python installation.

BiteCode_dev 4y ago
I would advice against all of those recommandations. It would be very long to explain point by point, but in short, my experience is that if someone is asking OP's question, they don't have the experience to deal with the modes of failure of what you are proposing There is not a lot of things I'm very adament about. Yet when it comes to python env setup, I have a strong opinion on the matter, built from seing hundreds of people failing at it in a thousand ways. Looking for the best solution will not work. You have to go to the minimal one that does the job, which have the least possible ways to fail. And still work in 5 years. Most people like you, giving advices on HN, know too much about it to realize you solve lots of problems without even thinking when you perform your workflow. But the average python user don't have this knowledge. They just want to get things done and have something that works. I am very confident in these claims, although a HN comment is not the best format to demonstrate it. I should write an article on it honestly at this point because so many devs are suffering for this. A new team has been put in place to work on packaging officially in python. But the fruits will take years to mature.
- ActorNightly 4y ago
  Can you give me at least one of the points that you disagree with and reasons why?
  - BiteCode_dev 4y ago
    The first one, build from sources, is incredibly easy to get wrong. You may end up with an incomplete python without proper tkinter, ssl or zip support. Sometimes it will look like it works, only to fail later down the line when you use some part of openssl that requests don't exercice often or when you install numpy/scipy wheels. Not to mention someone will do "make install" instead of "altinstall" and break their machine with a 3 letters mistake since apt or rpm python will get erased. If you wonder how to setup a python venv, you should not compile anything (so no oyenv neiter). In the same way that if you wonder what oil to put in your car, you should not attempt to fix your breaks. The fact you suggested it underlines my point that you are too experienced with the stack to give advices that would be useful for most confused devs in python. A C# dev that starts python just wants, and needs, one reliable happy path. In fact, it's part of the problem. Paradox of choice, with too many solutions that won't fit the average user context. Funnily, now that I get close to 20 years of python, I find myself going back to the beginner stuff.
    - salawat 4y ago
      What's with the push to encourage people not to learn? Get em started, let em figure the rest out as they run into it. You aren't gonna be here forever. The test of a tool is learnability.
      - BiteCode_dev 4y ago
        Of they will learn. But instead of having to learn about how to setup python, they will spend the same time learning on how to solve their problem with python. Given that days have only 24 hours, the latter is more attractive to a lot of people.
    - ActorNightly 4y ago

BiteCode_dev 4y ago

I would advice against all of those recommandations. It would be very long to explain point by point, but in short, my experience is that if someone is asking OP's question, they don't have the experience to deal with the modes of failure of what you are proposing There is not a lot of things I'm very adament about. Yet when it comes to python env setup, I have a strong opinion on the matter, built from seing hundreds of people failing at it in a thousand ways. Looking for the best solution will not work. You have to go to the minimal one that does the job, which have the least possible ways to fail. And still work in 5 years. Most people like you, giving advices on HN, know too much about it to realize you solve lots of problems without even thinking when you perform your workflow. But the average python user don't have this knowledge. They just want to get things done and have something that works. I am very confident in these claims, although a HN comment is not the best format to demonstrate it. I should write an article on it honestly at this point because so many devs are suffering for this. A new team has been put in place to work on packaging officially in python. But the fruits will take years to mature.

ActorNightly 4y ago
Can you give me at least one of the points that you disagree with and reasons why?
- BiteCode_dev 4y ago
  The first one, build from sources, is incredibly easy to get wrong. You may end up with an incomplete python without proper tkinter, ssl or zip support. Sometimes it will look like it works, only to fail later down the line when you use some part of openssl that requests don't exercice often or when you install numpy/scipy wheels. Not to mention someone will do "make install" instead of "altinstall" and break their machine with a 3 letters mistake since apt or rpm python will get erased. If you wonder how to setup a python venv, you should not compile anything (so no oyenv neiter). In the same way that if you wonder what oil to put in your car, you should not attempt to fix your breaks. The fact you suggested it underlines my point that you are too experienced with the stack to give advices that would be useful for most confused devs in python. A C# dev that starts python just wants, and needs, one reliable happy path. In fact, it's part of the problem. Paradox of choice, with too many solutions that won't fit the average user context. Funnily, now that I get close to 20 years of python, I find myself going back to the beginner stuff.
  - salawat 4y ago
    What's with the push to encourage people not to learn? Get em started, let em figure the rest out as they run into it. You aren't gonna be here forever. The test of a tool is learnability.
    - BiteCode_dev 4y ago
      Of they will learn. But instead of having to learn about how to setup python, they will spend the same time learning on how to solve their problem with python. Given that days have only 24 hours, the latter is more attractive to a lot of people.
  - ActorNightly 4y ago