Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to make a Python package in 2021

antonz.org

Post reply on HN
Print view View original

101–110 of 215 posts

Re: How to make a Python package in 2021

#101

Post by globular-toast »

neolog wrote: post #11
zomglings wrote: post #8

The number of extra tools used in this article boggles my mind. Are you writing a simple library? Create a setup.py. Copy paste an existing setup.py and modify it to suit your purposes. Now you have a working, pip installable python package. Want to publish to PyPI? Use twine. It's standard and it's simple. You don't need complicated tooling for simple projects.

How do you handle version pinning? hash checking? CI? testing on multiple platforms? multiple python versions? deployment? credential management? package data? version bumps? Sure, experts know how to do all these things because they spent many days learning them, but I'd rather outsource to a tool.

You don't pin anything for a package. I'm not aware of any "standard" CI that a package tool could set up. I guess you mean testing on multiple versions, in which case tox will help. Deployment for a package is handled by twine. Package data? What about it? Version bumps should always be manual but I recommend setuptools-scm.

You seem to be confusing packages with "apps". It's very important to understand the clear distinction between these.

Re: How to make a Python package in 2021

#102

Post by 1337shadow »

amarshall wrote: post #97
1337shadow wrote: post #95

Still hardcoding version numbers in 2021? Why not use setupmeta

Probably because setupmeta seems to only supports setup.py, which this guide doesn’t use (and isn’t generally recommended for most use cases).

I maintain over 50 public packages with setup.py and most of them have setupmeta, it's great and I would recommend it for all use cases.

Re: How to make a Python package in 2021

#103

Post by atoav »

zomglings wrote: post #26
neolog wrote: post #21

Earlier quoted context omitted.

> You don't need to solve all those problems at once. Why spend time tweaking the setup when you can just get it right in the first place with less work?

Do you recommend poetry? I've been meaning to try it but haven't had the time to migrate an existing project to poetry.

I used poetry for multiple projects already and I quite like it because it makes version management really straightforward and you can just go like

  poetry new foo
And it will setup all the basic stuff for you right away. Having all the project dependecies and Metadata in pyproject.toml makes sense and reduces cognitive overload. Having poetry manage your venvs autmagically is a good extra.

There is still room for improvement, e.g. I had some trouble with their install script at times (python vs python3)

Re: How to make a Python package in 2021

#104

Post by phodge »

ThePhysicist wrote: post #98

The author mixes different things like linting and testing into the packaging process, which (IMHO) are not really part of making a package. The process is really much easier than this article makes it seem: - Write a simple setup.py file. - Generate a source or binary release by e.g. running "python setup.py sdist" - You're done! Adding a setup.py file is already enough to make your library pip-installable, so you c…

I don't see how your version is easier than the sequence of commands in the first few steps of the article, which is basically `pip install flit; flit init; flit publish`. Flit is just as easy to install as twine, but you save yourself the hassle of having to write a setup.py.

Re: How to make a Python package in 2021

#105

Post by tcbasche »

spondyl wrote: post #55
tcbasche wrote: post #24

Earlier quoted context omitted.

How does it compare to pipenv?

From memory, there was a whole thing where pipenv, created by Kenneth Reitz of requests fame, was misaccurately portrayed as the official successor to pip when that wasn't true

I recall this, but I wasn’t quite clear on what the issue was with pipenv itself (other than questionable behaviour from the author)

Re: How to make a Python package in 2021

#106

Post by ThePhysicist »

phodge wrote: post #104
ThePhysicist wrote: post #98

The author mixes different things like linting and testing into the packaging process, which (IMHO) are not really part of making a package. The process is really much easier than this article makes it seem: - Write a simple setup.py file. - Generate a source or binary release by e.g. running "python setup.py sdist" - You're done! Adding a setup.py file is already enough to make your library pip-installable, so you c…

I don't see how your version is easier than the sequence of commands in the first few steps of the article, which is basically `pip install flit; flit init; flit publish`. Flit is just as easy to install as twine, but you save yourself the hassle of having to write a setup.py.

Maybe I'm too old-fashioned then. But I like that you don't have any dependencies when using distutils/setuputils with a `setup.py` file, so if you don't distribute your code you're already done. I'm also not a fan of tools that are just wrappers around other tools.

Re: How to make a Python package in 2021

#109

Post by hardwaresofton »

darthrupert wrote: post #81
zomglings wrote: post #8

The number of extra tools used in this article boggles my mind. Are you writing a simple library? Create a setup.py. Copy paste an existing setup.py and modify it to suit your purposes. Now you have a working, pip installable python package. Want to publish to PyPI? Use twine. It's standard and it's simple. You don't need complicated tooling for simple projects.

I actually think one should do the exact opposite to what you're suggesting. I've experienced modern package management through Cargo and anything below that level now seems like returning to stone age. In the python ecosystem, poorly defined packages is a wide problem. You never know what you get in the next version upgrade. So my suggestion: burn all the "simple" python packaging tools in a big fire and move eveyth…

Bit of a side note but remember cargo learned a lot from generations of package managers, across languages. It essentially represents some of the best that package managers have to offer. You only get that kind of result by starting from scratch every few years (as in, rust started from scratch when the Node/NPM ecosystem had been around for years to steal ideas from, Haskell had been around for years to steal language design from, etc.).

Rust is incredibly lucky to have been created when it was because it benefits immensely from these things (I think it's the best new-to-middle-aged production-usable systems language out there today).

I agree with the idea but languages like Python and their ecosystems are really hard to move (remember python 2->3? is that even over?) -- it's a herculean and often impossible task.

Re: How to make a Python package in 2021

#110

Post by takluyver »

erezsh wrote: post #64
carreau wrote: post #10

Earlier quoted context omitted.

Thomas is well know as one of the maintainer of IPython and Jupyter, and developed flit while working on the pep for pyproject.toml and the pip backend allowing things like python -m build. Though `python -m build` only works _if_ you use something like flit or setup.py in the backend to do build the package and hence why you can set flit as a build-backend. So yes, flit is one of the latest tool, and yes it is one o…

How does flit compare to poetry? The seem to be both doing the same thing, and in a very similar way.

Poetry does much more than Flit, like resolving dependencies, creating a lock file, and managing an environment where you can run your code. In particular, Poetry is meant to support application development (where you want to have a fixed version of your dependencies) as well as library development.

Flit is more aimed at being the simplest possible thing to put a package on PyPI, if that's all you want to do. It expects you to list dependencies in pyproject.toml manually.

Post reply on HN