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

121–130 of 153 posts

Re: How to create a Python package in 2022

#121

Post by dflock »

RojerGS wrote: post #114
zwirbl wrote: post #54

Earlier quoted context omitted.

I think the font size is perfect, but I take offense to the font used for headings

I've been looking for a replacement for that font for a long time. Do you have any suggestions?

You could just use the same font as your body copy - "Atkinson Hyperligeible" with `line-height: 0.8` and `font-weight: 700` - and remove the `font-size: .8rem;` from your `body` rule.

If you want to keep a similar style: https://fonts.google.com/?category=Handwriting

Also: https://www.pagecloud.com/blog/best-google-fonts-pairings

Re: How to create a Python package in 2022

#122

Post by mwarkentin »

bvrmn wrote: post #112
Spivak wrote: post #97

Earlier quoted context omitted.

> Poetry thing because… pip freeze doesn't pin transitive dependencies and so you have to pick something and Poetry is fine and actively developed. > virtualenv, because that's just what you have to do when dealing with messed up dependencies No that's what you do when you have multiple dependency trees for different projects on your system. Somehow people got the message that global variables were bad but still thin…

> pip freeze doesn't pin transitive dependencies AFAIK it lists all installed packages and hence pins all dependencies.

Yes, unfortunately all dependencies are frozen at the same level, so it becomes really hard to distinguish between what your actual dependencies, and sub-dependencies, and sub-sub-dependencies are.

Re: How to create a Python package in 2022

#123

Post by radonek »

matheusmoreira wrote: post #95
sigmonsays wrote: post #90

Earlier quoted context omitted.

the irony here is python packaging has sucked forever, and this is just another example of it. "Do more with less" has never entered the average python developers mind. you'd think herd mentality might help it but it only creates more packaging solutions. Now days, I've stopped using python outside of tiny scripts and I will never touch it for a large project.

The problem with Python is it's too successful. It has too many useful libraries. I don't really like it very much but it's really hard to ignore it. There is exactly one thing I miss from Python packaging tools: developer mode. I can factor out parts of an application into a library and develop both at the same time by installing the library in editable mode and pointing to the library's local directory. This is som…

I'm not sure I understand this. Do you mean having an app instance using library code from local git instead of pip package? I do that all the time with a Makefile and some symlinks.

Re: How to create a Python package in 2022

#124

Post by plonk »

quantumduck wrote: post #21
plonk wrote: post #18

Earlier quoted context omitted.

We do a lot of deep learning and image processing and pip works much better for us. PyTorch makes wheels that contain all reauired DLLs on all systems. Maybe conda isn’t needed anymore.

Conda let's you install a specific cuda version directly in a virtual environment with one click though. It's really useful when you have to switch between multiple PyTorch versions and convinient in general imo.

The PyTorch wheel comes with its own CUDA DLLs, they can’t be shared with other libraries but they won’t be your problem to install that way.

Re: How to create a Python package in 2022

#125

Post by js2 »

js2 wrote: post #110
wyuenho wrote: post #57

I wish people would just forget about pre-commit, this thing is especially useless in a setting where a CI/CD pipeline exists. It's not that hard to write a simple Makefile or shellscript to run linters on push. Pre-commit is one of the most annoying tools that have come into existence in recent years that everyone seems to be cargo-culting. It doesn't play well with editors since in order to find the actual binary p…

Pre-commit can also be configured to use the project's dependencies, which is what I do with my repos when there is overlap. You don't have to use its built-in integrations. Indeed, I find its integrations most useful for tools that aren't specific to my project: things like the white-space checks, yaml checks, etc. You can also set things up the other way around, having the CI/CD system install and and run pre-commi…

Here's an example from one of my repos that mostly uses the repo's own installed dependencies so that I don't need to manage those in more than one place:

https://pastebin.com/raw/0SP3NvBS

Re: How to create a Python package in 2022

#127

Post by matheusmoreira »

radonek wrote: post #123
matheusmoreira wrote: post #95

Earlier quoted context omitted.

The problem with Python is it's too successful. It has too many useful libraries. I don't really like it very much but it's really hard to ignore it. There is exactly one thing I miss from Python packaging tools: developer mode. I can factor out parts of an application into a library and develop both at the same time by installing the library in editable mode and pointing to the library's local directory. This is som…

I'm not sure I understand this. Do you mean having an app instance using library code from local git instead of pip package? I do that all the time with a Makefile and some symlinks.

Yeah. Pip already has that feature built in. I've hacked up partial solutions for some other languages but they're not as seamless. For C I tried git submodules but it's not really designed for that.

Re: How to create a Python package in 2022

#128

Post by kanonade »

slingnow wrote: post #115
radonek wrote: post #87

What a great article. We start with learning that we absolutely need this Poetry thing because… it's what everyone else uses. It's refreshing to see author who can skip usual badly argued justifications and just plain admin that he does not know shit and is just following rest of the herd. Then we continue by "solving" depependencies by usual way of ignoring them and just freezing whatever happens to be present. Then…

I had the same reaction. Not much explaining, no justification for the tooling decisions, pushing more undocumented code to pypi because why not, "I saw this other package do this", etc. I guess it's great if you're just looking for a shortcut to push something up to pypi, but my guess is someone new to it won't really understand what's going on other than some vague sense that they're following "best practices". And…

Then go write your own opinionated article on your blog. For myself, I was already thinking about trying to develop a package and this gives me a nice starting point for doing so even if I don't use all the same tools to do it.

Re: How to create a Python package in 2022

#129

Post by doliveira »

fnord123 wrote: post #75
wyuenho wrote: post #70

Earlier quoted context omitted.

1. Because it defeats the purpose of pre-commit. 2. pre-commit install installs the hook by default. 3. If you happen to fail linting a few times a year, there's always an anal coworker telling your boss in a 1-on-1 you are not following some BS ways of working.

Tell me you use Emacs without telling me you use Emacs.

Curious, how does using Emacs affect that much the workflow to the point of pre-commit being so annoying?

Re: How to create a Python package in 2022

#130

Post by p33p »

iggy_knights wrote: post #105
Bullfight2Cond wrote: post #88

Poetry uses non-standard dependency specification formats. PDM is like Poetry but faster/more standards compliant. https://pdm.fming.dev/

Good thing about finally converging on some sort of standard means tools become more interoperable: Another good tool (which was endorsed by the PyPA) is Hatch - https://hatch.pypa.io/latest/environment/ I currently use PDM because it supports conda virtual environments for isolation, but am keeping an eye on Hatch.

Didn't they also endorse PipEnv and that turned into a flop?
Post reply on HN