search

s-hamann / desec-dns

A simple deSEC.io API client
MIT License
16 stars 5 forks source link

Poetry / Publishing on PyPi #9

Closed NiklasBeierl closed 5 months ago

NiklasBeierl commented 7 months ago

Hey there,

thanks for implementing this neat CLI. It got my attentiona because it seems to be the only tool that supports adding policies to tokens (the killer feature of desec for me). But it also seems to be the most "complete" one in general!

I have a few ideas for contributions but this one seemed the easiest to get started with:

I think it would be a great idea to publish the package on PyPi. To my knowledge, using poetry is the easiest way of doing that. I would be willing to handle the publishing and perhaps at some point packaging for some other package managers myself, but I didn't want to step on your turf - so I am first submitting this PR. :)

s-hamann commented 7 months ago

Hi and thanks for your contribution! Packaging for PyPI is something that I have on my mind for a long time but never really got around to. I even cobbled something together based on setuptools some years ago, but never really finished it (mostly, because I also want a test suite before doing proper releases and versions).

Unfortunately, I'm not really familiar with Python packaging and things have changed a bit in the last few years. I'm not sure poetry is the best way to go. I'm not a fan of locking dependency versions as that requires keeping track of security issues and other bug of all dependencies. I'd much rather trust dependency upstreams to improve with every release.

Are your familiar with any alternatives to poetry in today's Python packaging world?

NiklasBeierl commented 7 months ago

I have dabbled with some other build tools, but poetry is by far the most comprehensive and smooth experience I have had there. It usually just works. It can also address your concerns regarding version pining: One can ease the constraints to something like "at least" or semver-compatible with major version X. There is an entire section section in the documentation on that.

Having tests before going live is a stance I can get behind, perhaps I can contribute some in the next weeks.

s-hamann commented 7 months ago

Reading up on the topic, it seems that python packaging is still a mess. I'm not sure I like poetry, due to its approach to version capping, being somewhat centred around the lock file and the (current) lack of support for PEP-621. PDM looks better in those regards and has a similar feature set. Do you have any experience with it?

NiklasBeierl commented 6 months ago

I am afraid I don't understand your concern about version capping and the lock file.

The lock file is a snapshot of the concrete dependency versions that poetry resolved to when installing dependencies for the first time. The resolution is derived from the contents of pyproject.toml and currently available packages. It gets updated whenever you add/remove dependencies via poetries CLI or when you explicitly update it with poetry lock. The purpose is to have a reproducible environment for CI tools or anyone who installs your project from source (this repo).

It has no impact on the versions constraints that are added to the Metadata of the PyPi packages and thus on anyone who installs the package from PyPi. The depedency-metadata is generated from pyproject.toml and can be as strict or loose as you like them to be. * is happy with any version.

For the most part, lock-files are an "opt in" mechanism. I can remove it form the tree if you prefer. From my personal experience, having a lock file for CI/CD and consistent environments for all developers is a godsent, but I am not here to preach. :smile:

Pep-621: As far as I understand the folks at poetry are working on that.

I have no experience with PDM. Looks cool, but realistically speaking I won't get around to checking it out in the next few months. That shouldn't deter you from trying it out, tho! I will probably get it to work for any other contributions if you set up the configuration. :)

s-hamann commented 6 months ago

I am afraid I don't understand your concern about version capping and the lock file.

The lock file is a snapshot of the concrete dependency versions that poetry resolved to when installing dependencies for the first time. The resolution is derived from the contents of pyproject.toml and currently available packages. It gets updated whenever you add/remove dependencies via poetries CLI or when you explicitly update it with poetry lock. The purpose is to have a reproducible environment for CI tools or anyone who installs your project from source (this repo).

It has no impact on the versions constraints that are added to the Metadata of the PyPi packages and thus on anyone who installs the package from PyPi. The depedency-metadata is generated from pyproject.toml and can be as strict or loose as you like them to be. * is happy with any version.

For the most part, lock-files are an "opt in" mechanism. I can remove it form the tree if you prefer. From my personal experience, having a lock file for CI/CD and consistent environments for all developers is a godsent, but I am not here to preach. 😄

Lock files seem like a good way to hide incompatibilities and other upcoming issues from developers and CI. I realize that they are optional, but poetry seems to strongly suggest using them. Deviating from a tool intended workflow might make things more complicated.

Pep-621: As far as I understand the folks at poetry are working on that.

Yes, but they don't seem to be making a lot of progress lately.

I have no experience with PDM. Looks cool, but realistically speaking I won't get around to checking it out in the next few months. That shouldn't deter you from trying it out, tho! I will probably get it to work for any other contributions if you set up the configuration. :)

That's an important point. PDM doesn't seem to have much of a user base at this time. I want to avoid throwing unfamiliar tooling at new contributors.

All things considered, Poetry seems like the best choice at the moment, despite my concerns with some of the design decisions. And I can always change the tool later, if I really can't come to terms with it :slightly_smiling_face:

NiklasBeierl commented 6 months ago

Sorry for the long radio silence, was an involved month at work. :v:

s-hamann commented 6 months ago

Sorry for the long radio silence, was an involved month at work. ✌️

No worries :slightly_smiling_face: Thanks for coming back to this. I think, this looks good now. Just two things before I'll merge:

  1. Please remove the dependency on black.
  2. Please squash your commits.
NiklasBeierl commented 5 months ago

Done

s-hamann commented 5 months ago

Thanks!