Honestly, I don't even bother "packaging" Python tools anymore. Just put it in all in a git repo, and pip can install using pip install git+https://myg.it/repo.git
But now packages on PyPI can't depend on it.
How to make a Python package in 2021
71–80 of 215 posts
Re: How to make a Python package in 2021
#72Earlier quoted context omitted.
Pipenv only targets applications; Poetry targets both applications and libraries. Pipenv has quite some drama behind it that I do not want to get into; in contrast, Poetry's development has been quite professional. Pipenv enjoys better tool support, e.g. it is recognized and supported by VS Code; but Poetry does not have the same level of support.
I don't know anything about pipenv drama, so by morbid curiosity I looked for it and this is the first thing I found: https://github.com/pypa/pipenv/issues/2228 This is one of the most ridiculous issues I've read. If the rest of the "drama" is like that, then eh.
The drama was surrounding false advertising so to speak. Pipenv promised a lot but did not quite deliver, much like the earlier days of MongoDB. But more importantly, it pretended or at least heavily implied it was an official PSF-affiliated project, when it was not. How that claim was substantiated was also subject to drama.
Re: How to make a Python package in 2021
#73I’m always glad to see Make being used. It’s such a powerful and simple tool that usually does the job just as well as more “bespoke” CLI’s for various frameworks and languages
I would strongly discourage using make on new projects, make syntax is full of footguns and quirks (not being able to pass multiple args to subcommands is an easy example).
Bash, Python, or even Typescript are much easier, safer, and more widely standardized environments to maintain and grow your scripts once you get past a few lines.
Re: How to make a Python package in 2021
#74I’m always glad to see Make being used. It’s such a powerful and simple tool that usually does the job just as well as more “bespoke” CLI’s for various frameworks and languages
I rather just write a bash script. It's the lowest common denominator. Make may not be installed by default in many places and it has some weird syntax quirks that make it annoying to use IMO. Here's an example of how I like to do my "bash scripts that sorta work like make": https://github.com/francislavoie/laravel-websockets-example/... basically each function is a "command", so I do like "./utils start" or whatever…
I like this style as well, we keep all our scripts in a ./bin directory, e.g. ./bin/lint.sh, ./bin/test.sh, etc. just as discoverable as make commands (run ls ./bin) and much easier to maintain.
If you really want make, you can also just call out to your bash scripts from make:
test:
./bin/test.sh
lint:
./bin/lint.sh
...Re: How to make a Python package in 2021
#75I prefer to put `.PHONY` before every phony target, not gather them all in one place.
When phony targets are all written out in the beginning of the Makefile, it's easy to forget to alter this list when a phony target is added or removed later.
This rarely causes an error, but still I've seen many Makefiles with outdated .PHONY lists.
Re: How to make a Python package in 2021
#76Earlier quoted context omitted.
I feel like the entire point of a BDFL is that they can just ignore this sort of thing and make the hard call, but it never happened.
Maybe it could still happen? It seems like a super high value challenge that the BDFL could take on: build out the official set of tools (setup.py, twine, virtualenv, pip) to support features that make people seek out alternatives (pyproject.toml, poetry, flit, conda, pyenv, pipenv).
I think the time has passed, both in terms of there no longer being a BDFL, as well as Python passing a point where the call can be made.
Re: How to make a Python package in 2021
#77Earlier quoted context omitted.
I feel like the entire point of a BDFL is that they can just ignore this sort of thing and make the hard call, but it never happened.
Maybe it could still happen? It seems like a super high value challenge that the BDFL could take on: build out the official set of tools (setup.py, twine, virtualenv, pip) to support features that make people seek out alternatives (pyproject.toml, poetry, flit, conda, pyenv, pipenv).
I realize this is controversial but from reading the docs I really thought Pipenv was the official solution. Took me a while to realize this wasn't the case.
Re: How to make a Python package in 2021
#78After reading this guide I would still recommend people to use this guide.
https://cjolowicz.github.io/posts/hypermodern-python-01-setu...
It's great for beginners and experts. As a long time python veteran it completely changed how I work with python for the better. It is lengthy with lots of optional steps. Just skip the ones you don't find relevant.
Re: How to make a Python package in 2021
#79Earlier quoted context omitted.
I feel like the entire point of a BDFL is that they can just ignore this sort of thing and make the hard call, but it never happened.
On the whole, Guido's career as a BDFL was astoundingly effective. Maybe he made the right call. It'd have been a terrible idea to alienate the science community just when data science was taking off as a field.
I'm not disagreeing, but I am curious if you have anything specific you would point to with regards to Guido's role being successful. I'm just ignorant really, it's not intended to be a leading question at all.
Re: How to make a Python package in 2021
#80Earlier quoted context omitted.
Maybe it could still happen? It seems like a super high value challenge that the BDFL could take on: build out the official set of tools (setup.py, twine, virtualenv, pip) to support features that make people seek out alternatives (pyproject.toml, poetry, flit, conda, pyenv, pipenv).
I think the time has passed, both in terms of there no longer being a BDFL, as well as Python passing a point where the call can be made.
Sadly I bet you’re right on this. My small sliver of hope is that Guido van Rossum’s ideas to “make using Python better” [1] include better packaging.