8 ms·

This looks great, will be giving it a go today to replace some increasingly complex bash scripts!

jacobtomlinson 3y ago
Awesome! Let me know how you get on and don't hesitate to open issues if you run into problems or have thoughts about the API design.
- kungfufrog 3y ago
  Without opening a philosophical discussion on Python package management what were the pragmatic reasons from switching from Poetry to Hatch? I'm about to run my first bit of kr8s code!
  - jacobtomlinson 3y ago
    Poetry is a locking package manager. That’s extremely useful for applications where you don’t want dependencies to drift. However for a library you want pinning a to be looser so the benefits of poetry aren’t as strong. Given that hatch is the official method from the PyPA it felt like a better choice.
usrk0123961 3y ago
Why not just use the official python kubernetes client? https://github.com/kubernetes-client/python https://github.com/kubernetes-client/python
- jacobtomlinson 3y ago
  I built kr8s because the official autogenerated library is extremely verbose, low level and hard to use. Kr8s is modelled after kubectl instead of the REST API to try and be more accessible to developers.
  - alpb 3y ago
    These low-level constructs in the client libraries exist so that people can build controllers and operators on top of it, no? There's a lot that goes into making of implementing a Kubernetes client such as keeping up with semantic changes (dry run, server-side apply, tracing, rate limiting, patch support etc). Does your library also cover these?
    - jacobtomlinson 3y ago
      Anything you can do with the official library you can do with kr8s. Some things will require writing low level HTTP requests if we haven’t implemented them yet, but it’s not so different to the official low level auto generated API. The goal here is to make easy things easy, while ensuring anything is possible.
- galenmarchetti 3y ago
  seconding the answer given by OP...I've also found the raw clients very low level and hard to use. I appreciate the higher level abstraction here, emphasis on "batteries included" and usability mirroring kubectl
- dharmab 3y ago
  The official python client does not have feature parity with kubectl; I had to reimplement parts of kubectl in my own scripts, like the 'apply' and 'exec' subcommands and less-flaky CRD deployments.
  - jacobtomlinson 3y ago
    Kr8s already has things like port forwarding and I’m working on apply right now. Exec is next on my list
    - dharmab 3y ago
      here, take my code: https://github.com/dharmab/homelab-k3s/blob/2f46393aeeb736736595ed830c259c7888a2a3e0/lab/main.py#L96 https://github.com/dharmab/homelab-k3s/blob/2f46393aeeb73673...
      - jacobtomlinson 3y ago
        Heh thanks. We are trying to avoid binary dependencies like kubectl because you can’t install the with pip.
        dharmab 3y ago
        that exec function is pure python, and the order of operations in that deploy function is important (initial deployment of resource out of order will likely either fail outright or cause certain Pods to fail to become read)

Awesome! Let me know how you get on and don't hesitate to open issues if you run into problems or have thoughts about the API design.

kungfufrog 3y ago
Without opening a philosophical discussion on Python package management what were the pragmatic reasons from switching from Poetry to Hatch? I'm about to run my first bit of kr8s code!
- jacobtomlinson 3y ago
  Poetry is a locking package manager. That’s extremely useful for applications where you don’t want dependencies to drift. However for a library you want pinning a to be looser so the benefits of poetry aren’t as strong. Given that hatch is the official method from the PyPA it felt like a better choice.

usrk0123961 3y ago

Why not just use the official python kubernetes client? https://github.com/kubernetes-client/python https://github.com/kubernetes-client/python

jacobtomlinson 3y ago
I built kr8s because the official autogenerated library is extremely verbose, low level and hard to use. Kr8s is modelled after kubectl instead of the REST API to try and be more accessible to developers.
- alpb 3y ago
  These low-level constructs in the client libraries exist so that people can build controllers and operators on top of it, no? There's a lot that goes into making of implementing a Kubernetes client such as keeping up with semantic changes (dry run, server-side apply, tracing, rate limiting, patch support etc). Does your library also cover these?
  - jacobtomlinson 3y ago
    Anything you can do with the official library you can do with kr8s. Some things will require writing low level HTTP requests if we haven’t implemented them yet, but it’s not so different to the official low level auto generated API. The goal here is to make easy things easy, while ensuring anything is possible.
galenmarchetti 3y ago
seconding the answer given by OP...I've also found the raw clients very low level and hard to use. I appreciate the higher level abstraction here, emphasis on "batteries included" and usability mirroring kubectl
dharmab 3y ago
The official python client does not have feature parity with kubectl; I had to reimplement parts of kubectl in my own scripts, like the 'apply' and 'exec' subcommands and less-flaky CRD deployments.
- jacobtomlinson 3y ago
  Kr8s already has things like port forwarding and I’m working on apply right now. Exec is next on my list
  - dharmab 3y ago
    here, take my code: https://github.com/dharmab/homelab-k3s/blob/2f46393aeeb736736595ed830c259c7888a2a3e0/lab/main.py#L96 https://github.com/dharmab/homelab-k3s/blob/2f46393aeeb73673...
    - jacobtomlinson 3y ago
      Heh thanks. We are trying to avoid binary dependencies like kubectl because you can’t install the with pip.
      - dharmab 3y ago
        that exec function is pure python, and the order of operations in that deploy function is important (initial deployment of resource out of order will likely either fail outright or cause certain Pods to fail to become read)