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

How to create a Python package in 2022

mathspp.com

Post reply on HN
Print view View original

41–50 of 153 posts

Re: How to create a Python package in 2022

#41

Post by dannyboland »

zmmmmm wrote: post #38

I really dislike the Python convention of plonking source code effectively in the root directory. It means literally any random thing in there can get picked up if you put your package in the PYTHONPATH. Is there a reason the Python world did not standardise on putting source code in a "src" directory like every other language?

Yeah, I adopted the “src” dir layout after reading this post some time back:

https://blog.ionelmc.ro/2014/05/25/python-packaging/#the-str...

It describes some of the outdated motivations for the other layouts commonly seen with python, as well as the many benefits of the “src” layout.

Re: How to create a Python package in 2022

#42

Post by pid-1 »

woodruffw wrote: post #6

This is really nicely written; kudos to the author for compiling a great deal of information in a readable format. If I can be forgiven one nitpick: Poetry does not use a PEP 518-style[1] build configuration by default, which means that its use of `pyproject.toml` is slightly out of pace with the rest of the Python packaging ecosystem. That isn't to say that it isn't excellent, because it is! But you the standards ha…

> By way of example, here's a project that's completely PEP 517 and PEP 518 compatible without needing a setup.py or setup.cfg[2]. Everything goes through pyproject.toml.

Using pyproject.toml with pip / flit still has many rough edges such as pip being unable to install deps locally for development or not generating lock files. Poetry is way more mature IMO.

Re: How to create a Python package in 2022

#43

Post by zeotroph »

diekhans wrote: post #23

Lot of good info and saved away! However, it drinks the code coverage cool-aid that started like 30 years ago when code coverage tools emerged. Management types said "high test code coverage == high quality"; lets bean count that!! A great way to achieve high code coverage is to have less than robust code that does not check for crazy error cases that are really hard to reproduce in test cases. Code coverage is a too…

Python is the language with one of the highest 100%-coverage-to-effort ratios. The included unittest.mock framework is making it quite easy to trigger obscure errors and ensure they are handled properly.

Combined with thoughtful use of `# pragma: no cover` a 98% code coverage nowadays is an immediate warning that something was rushed. With this and type checking I feel RuntimeErrors much easier to avoid these days.

And typing, not even a mention?! :) But otherwise a great article, thank you!

Re: How to create a Python package in 2022

#46

Post by TOMDM »

This is a fantastic resource.

Are there any similar resources for setting up internal packages that you don't intend to publish publicly?

I can think of a number of situations where I would have benifitted from it, but the process of configuring a package to publish, hosting it and then pulling it when necessary is a mystery to me.

Re: How to create a Python package in 2022

#48

Post by pydry »

diekhans wrote: post #23

Lot of good info and saved away! However, it drinks the code coverage cool-aid that started like 30 years ago when code coverage tools emerged. Management types said "high test code coverage == high quality"; lets bean count that!! A great way to achieve high code coverage is to have less than robust code that does not check for crazy error cases that are really hard to reproduce in test cases. Code coverage is a too…

100% coverage as a side effect of careful testing isnt a red flag.

Coverage is a decent (among other things) measure unless it becomes a target. Once it becomes a target you get shitty rushed tests that act mostly as cement surrounding current behavior - bugs and all.

Re: How to create a Python package in 2022

#49

Post by milliams »

woodruffw wrote: post #6

This is really nicely written; kudos to the author for compiling a great deal of information in a readable format. If I can be forgiven one nitpick: Poetry does not use a PEP 518-style[1] build configuration by default, which means that its use of `pyproject.toml` is slightly out of pace with the rest of the Python packaging ecosystem. That isn't to say that it isn't excellent, because it is! But you the standards ha…

I believe that Poetry does conform to PEP 518 (i.e. it specifies `[build-system]requires/build-backend`), but not to the `dependencies` part of PEP 621 [1]. There are plans for this in the future though [2]. Though I would defer to your expertise if I'm mistaken.

[1] https://peps.python.org/pep-0621/

[2] https://github.com/python-poetry/roadmap/issues/3

Re: How to create a Python package in 2022

#50

Post by diarrhea »

zmmmmm wrote: post #38

I really dislike the Python convention of plonking source code effectively in the root directory. It means literally any random thing in there can get picked up if you put your package in the PYTHONPATH. Is there a reason the Python world did not standardise on putting source code in a "src" directory like every other language?

Python puts source code in a directory with the package's name. That's why the source code is really under `repo_root/package/`, not under `repo_root/` as you seem to imply. It's just that it's not called `src/`, but `package/` in Python (but that's configurable!).

So if you have a project called "splitter", your source code really lives under `splitter/splitter/`. I would agree that seems a bit redundant and `splitter/src` look better, but the source code is not in the project root.

Post reply on HN