License and pyproject.toml

[Joshua Megnauth]

License

I noticed that your repository doesn't have a LICENSE file. An unlicensed repository on GitHub defaults to all rights reserved. In other words, your code is legally neither open source nor free.

I'm assuming that you don't want this, so you should pick a license from Choose a License. 😸 You only need to copy the license text to a file called LICENSE in your project's root directory. There are several licenses you may use, but you don't have to overthink your choice. The two major philosophies are permissive, such as the MIT license; and copyleft, such as the GNU General Public License.

Choose a License is pretty clear, but I can try to clarify anything if you have questions. You should also add a license to any other repositories you own even if they're private.

pyproject.toml

setup.cfg and requirements.txt are part of the older method for distributing Python packages and venv is the older way of managing virtual environments. Over the years, Python developers created a passel of competing tools to ease dependency management, distribution, and virtual environments. Wading through all of these different tools is not only difficult but makes the ecosystem feel intractable, especially considering that these tools solve the same problems in different ways.

The Python Software Foundation (i.e., the nonprofit managing Python as a language) consolidated these different formats into pyproject.toml. pyproject.toml is similar to Rust's cargo.toml, npm (JavaScript)'s package.json, Ruby's gemfile, and others. Poetry is a tool that leverages the full power of pyproject.toml to make dependency management and environments much neater and easier as well.

• Simple poetry guide and explanation.
• A more detailed explanation.

You don't have to switch over to a modern tool like poetry right away, but it's worth knowing that it exists for the future. Here's an example pyproject.toml for your repository created via poetry. (You totally need to add a license though.)

[tool.poetry]
name = "new-albums"
version = "0.1.0"
description = "A python script to update a Spotify playlist every day with all the songs from any significant new albums."
keywords = ["spotify", "scrape", "net"]
authors = ["Rivers Cuomo"]
license = "MIT"
readme = "README.md"
repository = "https://github.com/riverscuomo/new-albums"

[tool.poetry.dependencies]
python = "^3.8"
argparse = "^1.4.0"
pycountry = "^22.3.5"
python_dateutil = "^2.8.2"
python-decouple = "^3.6"
rich = "^11.2.0"
spotipy = "2.20.0"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

[Andrew Colello]

would like to chip in here to wholeheartedly agree on all fronts from my point of view, i was about to make a similar ticket.

one of the recently merged PRs introduces an older way of doing package management, while the way described here is much more modern in my opinion.

furthermore, lack of a license is a legitimate OSS issue that would need addressing in a true open source project. i would also agree with the permissive license recommendation (MIT) based on my understanding of the stated goals for this project.

[SunPowered]

+1 over here. A proper license is a really great suggestion.

[Rivers Cuomo]

Thanks, everyone. License added.

[Rivers Cuomo]

Regarding poetry, I actually originally set up this package with poetry after hearing about it on the "Talk Python To Me" podcast. Then I removed it right before opening this repo. I couldn't figure out how it was an improvement. The downsides included: cluttering up the package with files and folders I didn't understand; requiring that I run the program with "poetry run python" instead of "py"; and most importantly, I couldn't tell if it was even a tool that was gaining widespread adoption. The "old" way seemed simpler and more popular.

However, based on what you guys are saying here, I'll definitely give it another look. Good timing, too, as I'm just packaging up another project to share on github.

[SunPowered]

@riverscuomo I tend to agree with you on using poetry. It can be useful and not all that terrible, but Python has switched up its recommended packaging system every couple years, and I don't feel it's always been a step forward.

Specifically, I remember the pip install . -e not working anymore, or the older python setup.py develop. Both super useful in my simpler development flow. Its been over a year since last working with it so give it a go. It is the recommended way, at the moment.

[Joshua Megnauth]

@SunPowered I think poetry install does the equivalent of pip install . -e, but that may have been different when you tried it.

You bring up a great point in terms of recommended packaging changes. Python is older than sometimes assumed—the first version predates the Blue album! In those years, especially within the last decade and a half or so, the ecosystem accumulated the detritus of "best practices" or competing ways of solving the same problem. This isn't Python specific; C++ and Java have similar issues, especially with build systems, but in any case it's hard to know exactly what to do or which tools to pick.

I initially used Anaconda as a package manager because I learned Python for data science. Anywho, Anaconda quickly becomes a maintenance nightmare for environments with more than a handful of packages. I ended up just installing Python libraries with paru, a package manager for Arch Linux which is a terrible idea for distribution because those are all system packages. 😹I only recently upgraded my tooling. venv, requirements.txt, and setup.py work well, but I've always felt they were a bit too finicky and hands on, especially for a language like Python. poetry coupled with the PEPs that inspired it feel a lot more modern and simple in comparison. It reminds me of Rust's cargo!

With that said, @riverscuomo you can use whichever method you like best or even try other tools like pipenv. Programming is full of choices like this where there isn't a single right answer. 😄

Edit: Also, I'll close this since you added the license.