4 ms·

> But personally so far everytime I have come across something not using a task runner it has just been the wrong decision. Yeah, tends to happen a lot when yo

> But personally so far everytime I have come across something not using a task runner it has just been the wrong decision. Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering" causing similarly sized future issues. But then I also know everyone's history is vastly different, my views are surely shaped by the specific issues I've witnessed (and sometimes contributed to :| ), than anything else.

Storment33 10mo ago
> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. Strong opinions, loosely held :) > Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering" Funnily enough running with the first idea I think is creating a lot of the "over-engineering" I am seeing. Not stopping to consider other simpler solutions or even if the problem needs/is worth solving in the first place. > Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. I quickly asked Claude to convert one of my open source repos using Make/Nix/Shell -> Python/Nix to see how it would look. It is actually one of the better Python as a task runners I have seen. * https://github.com/DeveloperC286/clean_git_history/pull/431 https://github.com/DeveloperC286/clean_git_history/pull/431 While the Python version is not as bad as I have seen previously, I am still struggling to see why you'd want it over Make/Shell. It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI). It is less maintainable as it is more code, roughly x3 the amount of the Makefile. To me the Python code is more verbose and not as simple compared to the Makefile's target so it is less readable as well.
- Imustaskforhelp 10mo ago
  > It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI). UV scripts are great for this type of workflow There are even scripts which will install uv in the same file effectively making it just equivalent to ./run-file.py and it would handle all the dependency management the python version management and everything included and would work everywhere https://paulw.tokyo/standalone-python-script-with-uv/ https://paulw.tokyo/standalone-python-script-with-uv/ Personally I end up just downloading uv and so not using the uv download script from this but if I am using something like github action which are more (ephemeral?) I'd just do this. Something like this can start out simple and can scale much more than the limitations of bash which can be abundant at times That being said, I still make some shell scripts because executing other applications is first class support in bash but not so much in python but after discovering this I might create some new scripts with python with automated uv because I end up installing uv on many devices anyway (because uv's really good for python) I am interested in bun-shell as well but that feels way too much bloated and even not used by many so less (AI assistance at times?) and I haven't understood bun shell at the same time too and so bash is superior to it usually
  - quotemstr 10mo ago
    This thing does a global uv install when run? That's obnoxious! Never running stuff from whoever wrote this. Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.
    - Imustaskforhelp 10mo ago
      Does it really matter if its a global install of uv or not especially on Github Actions Also if this still bothers you, nothing stops you from removing the first x lines of code and having it in another .py file if this feels obnoxious to you > Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software. Regarding author suggest its removes itself its because it does still feel clutterish but there is virtually 0 overhead in using/having it still be if you are already using uv or want to use uv Oh also, (I am not the Author) but I have played extensively with UV and I feel like the script can definitely be changed to install it locally rather than globally. They themselves mention it as #overkill on their website but even then it is better than whatever github action is

Storment33 10mo ago

> Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. Strong opinions, loosely held :) > Typically I see larger issues being created from "under-engineering" and just rushing with the first idea people can think of when they implement things, rather than "over-engineering" Funnily enough running with the first idea I think is creating a lot of the "over-engineering" I am seeing. Not stopping to consider other simpler solutions or even if the problem needs/is worth solving in the first place. > Yeah, tends to happen a lot when you hold strong opinions with strong conviction :) Not that it's wrong or anything, but it's highly subjective in the end. I quickly asked Claude to convert one of my open source repos using Make/Nix/Shell -> Python/Nix to see how it would look. It is actually one of the better Python as a task runners I have seen. * https://github.com/DeveloperC286/clean_git_history/pull/431 https://github.com/DeveloperC286/clean_git_history/pull/431 While the Python version is not as bad as I have seen previously, I am still struggling to see why you'd want it over Make/Shell. It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI). It is less maintainable as it is more code, roughly x3 the amount of the Makefile. To me the Python code is more verbose and not as simple compared to the Makefile's target so it is less readable as well.

Imustaskforhelp 10mo ago
> It introduces more dependencies(Python which I solved via Nix) but others haven't solved this problem and the Python script has dependencies(such as Click for the CLI). UV scripts are great for this type of workflow There are even scripts which will install uv in the same file effectively making it just equivalent to ./run-file.py and it would handle all the dependency management the python version management and everything included and would work everywhere https://paulw.tokyo/standalone-python-script-with-uv/ https://paulw.tokyo/standalone-python-script-with-uv/ Personally I end up just downloading uv and so not using the uv download script from this but if I am using something like github action which are more (ephemeral?) I'd just do this. Something like this can start out simple and can scale much more than the limitations of bash which can be abundant at times That being said, I still make some shell scripts because executing other applications is first class support in bash but not so much in python but after discovering this I might create some new scripts with python with automated uv because I end up installing uv on many devices anyway (because uv's really good for python) I am interested in bun-shell as well but that feels way too much bloated and even not used by many so less (AI assistance at times?) and I haven't understood bun shell at the same time too and so bash is superior to it usually
- quotemstr 10mo ago
  This thing does a global uv install when run? That's obnoxious! Never running stuff from whoever wrote this. Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software.
  - Imustaskforhelp 10mo ago
    Does it really matter if its a global install of uv or not especially on Github Actions Also if this still bothers you, nothing stops you from removing the first x lines of code and having it in another .py file if this feels obnoxious to you > Oh, and later the author suggests the script modify itself after running. What the fuck. Absolutely unacceptable way to deploy software. Regarding author suggest its removes itself its because it does still feel clutterish but there is virtually 0 overhead in using/having it still be if you are already using uv or want to use uv Oh also, (I am not the Author) but I have played extensively with UV and I feel like the script can definitely be changed to install it locally rather than globally. They themselves mention it as #overkill on their website but even then it is better than whatever github action is