3 ms·

Python is such a massive dependency though, people who code in python rarely realize how big of a barrier it is for people not in that ecosystem. Package manage

by tjoff 3y ago

Python is such a massive dependency though, people who code in python rarely realize how big of a barrier it is for people not in that ecosystem. Package management is insane and every project has its own way of dealing with it. Installing python by itself is a chore on many operating systems.

BiteCode_dev 3y ago
Agreed. I wish more projects would compile their Python tool into a stand alone executable so that the users wouldn't have to deal with the installation process. I will at some point write about how to do that with Python, so that the knowledge will more broadly available and maybe the community will grow the habit of doing it. Meanwhile, I don't have more to offer than the "Relieving your Python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-pain https://www.bitecode.dev/p/relieving-your-python-packaging-p... It's not perfect, but it's an improvement for any people that don't do a lot of Python but has to.
- tjoff 3y ago
  Excellent, one of the problems with this is that you can't google it. Well, of course you can but you'll get a million contradicting resources and all that float to the top are too basic anyway. I really enjoyed your post, saved and will pass it along. The mentioned "follow-up" article: https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv (if you find the time, please add a link to it to make it even more complete)
  - BiteCode_dev 3y ago
    Thanks a lot, I planned to do it and I forgot. I've just added the link and it's indeed way better like this. Substack doesn't really have any way to make a series of articles, or to bundle stuff together, so linking manually is the only thing you can do that will give a little structure. One more reason to move off it when I find the time.
deleted 3y ago
[deleted]
slondr 3y ago
Ruby is much better on the package management front and may be better suited to this task overall.
- BiteCode_dev 3y ago
  Having try both, I would say quite the opposite. Ruby package management is lacking in many ways. E.G: there is not good build in solution to manage projects and multiple versions of ruby on windows, it's all 3rd party. And C-extensions are still terrible to install The apparent simplicity comes from the fact the ruby ecosystem is much smaller than the Python one, with 95% of it revolving around ror, so you are more often on the happy path and see less errors.
mid-kid 3y ago
You can't run linux without python these days, and it's not hard to stick to packages available in the repositories.
- Brian_K_White 3y ago
  Incorrect.
- BiteCode_dev 3y ago
  It's very rare, most distros ship Python, and even mac does it. But: - Half of the devs in the world are on Windows. - Installing doit with pip is not trivial. Hence the "Relieving python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-pain https://www.bitecode.dev/p/relieving-your-python-packaging-p... And most people will never ever encounter this article, so they will hit a missing command, a missing package, a PATH error, a PYHONPATH error, a version error or something like that. They may even try to solve it by copy/pasting many commands from the web, some of them with admin right, and make a mess of their setup. That's why, for end user tools like doit, providing a stand alone executable is still the best solution.
  - mid-kid 3y ago
    Thankfully, every major distribution packages doit, so you don't need to touch pip at all https://repology.org/project/doit/information https://repology.org/project/doit/information
Brian_K_White 3y ago
And it breaks over time. Absolutely terrible choice for makefile. It would be far better to just use bash, even though it would mean coding your own dependecy and update-detecting logic. I wouldn't write anything in python that I still wanted to work a month later or on even one other system.
- appplication 3y ago
  Could you elaborate on what you mean by it breaks over time?
  - retrac 3y ago
    Python has no standard and the language implemented by the reference compiler is a moving target. (E.g. every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2.). The ecosystem in general is similarly dynamic. It's common to install a set of specific versioned packages and Python interpreter to get a package running. It's not really a language where you can write something and be confident it'll still work in ten years with the latest release of Python that'll be shipping with distros.
    - appplication 3y ago
      I don’t disagree with you, but I also don’t think that’s a bad thing. Things certainly don’t break quickly, there are years of warnings for deprecated functionality. I also think it’s not a bad thing to drop old functionality. It may not be warranted that code that worked 10/20 years ago should still work today. Languages evolve, and by pruning old features, footguns, or bad patterns, the language can evolve without carrying the weight of every mistake or legacy feature.
    - BiteCode_dev 3y ago
      > every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2 People had 15 years to move from 2 to 3. I had to port dodo files from 2 to 3, it's a 10 minutes job. Most of the time, running 2to3 on it does the job automatically. After all, you only use the stlib for task runners, delegating a lot of work to bash, and they are quite short. > It's not really a language where you can write something and be confident it'll still work in ten years I still have Python 2.7 projects running fine, and reinstalled one serving half million users a few month ago. But even without this, Python was created in 1991, and Python 3 was released in 2008, that's 17 years between first release and the first big migration. To compare, go is 14 years old. In total. Plus your build file will have been edited so many times by the end 10 years anyway. Make has a lot going for it, but this is a terrible argument.

by tjoff 3y ago

BiteCode_dev 3y ago

Agreed. I wish more projects would compile their Python tool into a stand alone executable so that the users wouldn't have to deal with the installation process. I will at some point write about how to do that with Python, so that the knowledge will more broadly available and maybe the community will grow the habit of doing it. Meanwhile, I don't have more to offer than the "Relieving your Python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-pain https://www.bitecode.dev/p/relieving-your-python-packaging-p... It's not perfect, but it's an improvement for any people that don't do a lot of Python but has to.

tjoff 3y ago
Excellent, one of the problems with this is that you can't google it. Well, of course you can but you'll get a million contradicting resources and all that float to the top are too basic anyway. I really enjoyed your post, saved and will pass it along. The mentioned "follow-up" article: https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv https://www.bitecode.dev/p/back-to-basics-with-pip-and-venv (if you find the time, please add a link to it to make it even more complete)
- BiteCode_dev 3y ago
  Thanks a lot, I planned to do it and I forgot. I've just added the link and it's indeed way better like this. Substack doesn't really have any way to make a series of articles, or to bundle stuff together, so linking manually is the only thing you can do that will give a little structure. One more reason to move off it when I find the time.

deleted 3y ago

[deleted]

slondr 3y ago

Ruby is much better on the package management front and may be better suited to this task overall.

BiteCode_dev 3y ago
Having try both, I would say quite the opposite. Ruby package management is lacking in many ways. E.G: there is not good build in solution to manage projects and multiple versions of ruby on windows, it's all 3rd party. And C-extensions are still terrible to install The apparent simplicity comes from the fact the ruby ecosystem is much smaller than the Python one, with 95% of it revolving around ror, so you are more often on the happy path and see less errors.

mid-kid 3y ago

You can't run linux without python these days, and it's not hard to stick to packages available in the repositories.

Brian_K_White 3y ago
Incorrect.
BiteCode_dev 3y ago
It's very rare, most distros ship Python, and even mac does it. But: - Half of the devs in the world are on Windows. - Installing doit with pip is not trivial. Hence the "Relieving python packaging pain" procedure: https://www.bitecode.dev/p/relieving-your-python-packaging-pain https://www.bitecode.dev/p/relieving-your-python-packaging-p... And most people will never ever encounter this article, so they will hit a missing command, a missing package, a PATH error, a PYHONPATH error, a version error or something like that. They may even try to solve it by copy/pasting many commands from the web, some of them with admin right, and make a mess of their setup. That's why, for end user tools like doit, providing a stand alone executable is still the best solution.
- mid-kid 3y ago
  Thankfully, every major distribution packages doit, so you don't need to touch pip at all https://repology.org/project/doit/information https://repology.org/project/doit/information

Brian_K_White 3y ago

And it breaks over time. Absolutely terrible choice for makefile. It would be far better to just use bash, even though it would mean coding your own dependecy and update-detecting logic. I wouldn't write anything in python that I still wanted to work a month later or on even one other system.

appplication 3y ago
Could you elaborate on what you mean by it breaks over time?
- retrac 3y ago
  Python has no standard and the language implemented by the reference compiler is a moving target. (E.g. every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2.). The ecosystem in general is similarly dynamic. It's common to install a set of specific versioned packages and Python interpreter to get a package running. It's not really a language where you can write something and be confident it'll still work in ten years with the latest release of Python that'll be shipping with distros.
  - appplication 3y ago
    I don’t disagree with you, but I also don’t think that’s a bad thing. Things certainly don’t break quickly, there are years of warnings for deprecated functionality. I also think it’s not a bad thing to drop old functionality. It may not be warranted that code that worked 10/20 years ago should still work today. Languages evolve, and by pruning old features, footguns, or bad patterns, the language can evolve without carrying the weight of every mistake or legacy feature.
  - BiteCode_dev 3y ago
    > every script in Python 2 that used print without () broke in Python 3. There were other breaking changes. Some software still depends on installing Python 2 People had 15 years to move from 2 to 3. I had to port dodo files from 2 to 3, it's a 10 minutes job. Most of the time, running 2to3 on it does the job automatically. After all, you only use the stlib for task runners, delegating a lot of work to bash, and they are quite short. > It's not really a language where you can write something and be confident it'll still work in ten years I still have Python 2.7 projects running fine, and reinstalled one serving half million users a few month ago. But even without this, Python was created in 1991, and Python 3 was released in 2008, that's 17 years between first release and the first big migration. To compare, go is 14 years old. In total. Plus your build file will have been edited so many times by the end 10 years anyway. Make has a lot going for it, but this is a terrible argument.