Agree on mise. It's a great tool, really well implemented and easy to use. I've been trying to set up hk[0] this week and it's unfortunately not been as smooth a ride though.
that's fair. The DX of hk is a much harder problem since it will always require a decent amount of customization to fit into a project. I will be improving this though.
I'd probably say hk is the most challenging pre-commit manager to setup compared to its peers. That said, it's also the only one that can run hooks in parallel safely and deal with partially staged files where the others don't bother with these problems.
At least right now hk is good for folks that want the fastest and don't mind a bit of effort. Hopefully I can improve that and make it the best all-around.
How do you figure? I'm not involved with either project, but to my outsider eyes it seems like two completely different implementations of the same basic idea, with configuration that only looks necessarily similar to (i.e. there are only so many ways to write "here's how to look for secrets in 1Password" using TOML, which is a common configuration language and also one heavily used in the Rust ecosystem).
Also, devenv and mise also feel like different animals to me. I can't imagine many scenarios where I'd use them interchangeably.
Look at the problem statement, it's exactly the same. When I designed secretspec, I researched the space and no other tool approached secrets in such a way.
Syntax of toml is almost identical, the CLI as well.
It even has the same vocabulary.
I didn't dig deeper though, but I'd be surprised not to find more :)
[secrets.DATABASE_URL]
provider = "onepass"
value = "Database" # ← Item name in 1Password (fetches 'password' field)
[secrets.DB_USERNAME]
provider = "onepass"
value = "Database/username" # ← Specific field
[secrets.API_KEY]
provider = "onepass"
value = "op://Development/API Keys/credential" # ←
Is the similarity that they both refer to providers (as did Terraform and countless other config tools before it)? Or profiles (like aws-cli and countless other config tools before it)? Because other than that, I'm not really seeing it. And if I hadn't seen either of these, and my boss ordered me to implement something like them, I almost guarantee I'd use similar names for things because those are the common terms for them in industry.
Honestly, I'm not invested in either of these. They both look nifty, but I couldn't personally care less if either (or both or neither) of these catch on and become standards. I'm only commenting here because your statement here and on the linked discussion[2] ("it's almost a verbatim copy") seems incredibly aggressive, and to me, quite offputting. They don't look alike at all to me, other than that they both aim to do similar things and thus will have some natural overlap in terminology.
> I'm asking for an attribution given that the tool was copied, how is that aggressive?
Because it implies that the tool is copied. To me, they look similar, in a way that all tools like this are going to look somewhat similar.
> - fnix imports, - secretspec extends
So, they both have ways to slurp in other files so that you can kind of emulate inheritance. They call them different things, but the idea's similar: they both look similar to mise's configuration hierarchy, which predates both tools.[0]
> - secretspec profiles, - fnix profiles
They both support named profiles like "dev", "production", etc... like so many other devops tools that I'm having a hard time narrowing it down to one pre-existing example among thousands.
No, I'm still not seeing it. Fnox seems to be a copy of secretspec in the same way that Nginx is a copy of Apache, because they both do similar things and have config files that talk about domain names and ports and paths and certificates.
github.com is a popular website that lets you publish your git (a version control system) -based projects for others to read and contribute to.
In this case, the user “jdx” has published an issue (a bug or feature development tracker) about a complimentary project, but you can still access the source code and documentation about “mise” by clicking on the hyperlink labelled “mise” at the top of the page.
Love the thought put into mise and now fnox. They’re a joy to use.
Agree on mise. It's a great tool, really well implemented and easy to use. I've been trying to set up hk[0] this week and it's unfortunately not been as smooth a ride though.
[0] https://hk.jdx.dev/
that's fair. The DX of hk is a much harder problem since it will always require a decent amount of customization to fit into a project. I will be improving this though.
I'd probably say hk is the most challenging pre-commit manager to setup compared to its peers. That said, it's also the only one that can run hooks in parallel safely and deal with partially staged files where the others don't bother with these problems.
At least right now hk is good for folks that want the fastest and don't mind a bit of effort. Hopefully I can improve that and make it the best all-around.
It's cool to see almost verbatim copy of https://secretspec.dev :) I'm glad mise is catching up on https://devenv.sh features though.
How do you figure? I'm not involved with either project, but to my outsider eyes it seems like two completely different implementations of the same basic idea, with configuration that only looks necessarily similar to (i.e. there are only so many ways to write "here's how to look for secrets in 1Password" using TOML, which is a common configuration language and also one heavily used in the Rust ecosystem).
Also, devenv and mise also feel like different animals to me. I can't imagine many scenarios where I'd use them interchangeably.
Look at the problem statement, it's exactly the same. When I designed secretspec, I researched the space and no other tool approached secrets in such a way.
Syntax of toml is almost identical, the CLI as well.
It even has the same vocabulary.
I didn't dig deeper though, but I'd be surprised not to find more :)
I almost feel like we're looking at different things. From secretspec[0]:
From fnox[1]: Is the similarity that they both refer to providers (as did Terraform and countless other config tools before it)? Or profiles (like aws-cli and countless other config tools before it)? Because other than that, I'm not really seeing it. And if I hadn't seen either of these, and my boss ordered me to implement something like them, I almost guarantee I'd use similar names for things because those are the common terms for them in industry.Honestly, I'm not invested in either of these. They both look nifty, but I couldn't personally care less if either (or both or neither) of these catch on and become standards. I'm only commenting here because your statement here and on the linked discussion[2] ("it's almost a verbatim copy") seems incredibly aggressive, and to me, quite offputting. They don't look alike at all to me, other than that they both aim to do similar things and thus will have some natural overlap in terminology.
[0]https://secretspec.dev/concepts/declarative/
[1]https://github.com/jdx/fnox
[2]https://github.com/jdx/mise/discussions/6779#discussioncomme...
I'm asking for an attribution given that the tool was copied, how is that aggressive?
I'm not sure where you got the example, but here's fnox.toml from the link:
- fnix imports: https://github.com/jdx/fnox?tab=readme-ov-file#configuration...- secretspec extends: https://secretspec.dev/concepts/declarative/#multiple-inheri...
- secretspec profiles: https://secretspec.dev/concepts/profiles/
- fnix profiles: https://github.com/jdx/fnox?tab=readme-ov-file#profiles
> I'm asking for an attribution given that the tool was copied, how is that aggressive?
Your original comment is snarky and unprofessional. That's a bad look for projects that actually seem solid and impressive.
It's fine if you think your projects are better, and want to mention that. Just do it in a professional, objective way.
> I'm asking for an attribution given that the tool was copied, how is that aggressive?
Because it implies that the tool is copied. To me, they look similar, in a way that all tools like this are going to look somewhat similar.
> - fnix imports, - secretspec extends
So, they both have ways to slurp in other files so that you can kind of emulate inheritance. They call them different things, but the idea's similar: they both look similar to mise's configuration hierarchy, which predates both tools.[0]
> - secretspec profiles, - fnix profiles
They both support named profiles like "dev", "production", etc... like so many other devops tools that I'm having a hard time narrowing it down to one pre-existing example among thousands.
No, I'm still not seeing it. Fnox seems to be a copy of secretspec in the same way that Nginx is a copy of Apache, because they both do similar things and have config files that talk about domain names and ports and paths and certificates.
[0]https://mise.jdx.dev/configuration.html#configuration-hierar...
I have to agree... the linked Github files look like pretty generic config structures you'd find in projects, regardless of the tool or specification.
Any pointers to the cited mise, that I must admit I know nothing about?
https://github.com/jdx/mise
It's a generic version manager (replacing nvm/pyenv/etc). It also does direnv and tasks.
mise.jdx.dev/
There's no explanation or link to mise from that page that I can see. I now know what mise is, but that's from googling
github.com is a popular website that lets you publish your git (a version control system) -based projects for others to read and contribute to.
In this case, the user “jdx” has published an issue (a bug or feature development tracker) about a complimentary project, but you can still access the source code and documentation about “mise” by clicking on the hyperlink labelled “mise” at the top of the page.
The link in the post is literally on the Mise Github page. One click and you're on the main page reading the detailed README.
It's a dev tool manager
[dead]
From the initial feature set it sounds like Mozilla SOPS.