Are you of the opinion that because a behavior is legal that necessarily makes it right in all cases? If so, I suppose that is where I disagree.
595 karma · joined October 20, 2016
edit: as I express in a sibling comment this act is legally allowed of course, but is bad practice
- https://github.com/GoogleCloudPlatform/gcs-fuse-csi-driver
- https://github.com/ofek/csi-gcs
Here is the initial commit: https://github.com/GoogleCloudPlatform/gcs-fuse-csi-driver/c...
Notice for example not just the code but also the associated files. In the Dockerfile it blatantly copied the one from my repo, even the dual license I chose because I was very into Rust at the time. Or take a look at the deployment examples which use Kustomize which I like but is very uncommon and most Kubernetes projects provide Helm charts instead.
They were most certainly aware of the project because Google reached out to discuss potential collaboration but never responded back: https://imgur.com/a/KDuf9mj
- https://mail.python.org/archives/list/pypa-committers@python...
- https://mail.python.org/archives/list/pypa-committers@python...
Poetry is mainly used for managing an _application_ and its dependencies whereas Hatch is more agnostic to the project type and offers plugin-based functionality for the entire workflow (versioning, tox-like environments, publishing) so you can easily build things other than wheel/sdist, test in a Docker container, etc.
Hatch also strictly adheres to standards and eagerly adopts whatever behavior new PEPs dictate while Poetry has a persistent unwillingness to adopt new standards if they are deemed suboptimal (see comments on PEP 621 [1] and PEP 665 [2])
As such, locking support is temporarily blocked https://ofek.dev/hatch/latest/meta/faq/#libraries-vs-applica...
You can continue using other tools like Poetry at the same time https://ofek.dev/hatch/latest/meta/faq/#interoperability
By the way I very much appreciate the eye for design/UX of Poetry's creator, we also share strong opinions on pipenv :)
[1]: https://discuss.python.org/t/5243/12
[2]: https://github.com/python-poetry/poetry/issues/4710#issuecom...
Even fewer LoC :)
I'd prefer to use a memory-safe version :)
This sounds similar to the work I did [1] on the Datadog Agent, especially regarding the concept of each resource having its own circuit breaker.
My implementation is a bit different though, instead based on exponential decay like BGP Route Flap Damping [2]. It matches our use case a bit better and is easier to reason about.
I recently implemented our ClickHouse integration [1], so if any of you would like to try it out we would appreciate feedback. I really enjoyed learning about this database, and it has excellent docs :)
Oh fun fact, speaking of docs, this was the first integration of ours that we scrape docs for as part of the test suite. So when a new built-in metric is added it will fail our CI until we support it [2]. We just did this again for Apache Airflow [3].
[1]: https://github.com/DataDog/integrations-core/pull/4957
FD: I'm the author
Eventually, yes.