Round trip the Cargo.toml better about cargo-bump HOT 6 CLOSED

tomllib (I renamed toml_parser) is out now at version 0.1.1. It is currently limited to parsing documents, getting values, setting/changing values and getting subkeys of a key. From what I tell though cargo-bump gets the version, changes it, then sets the version, so this release should have everything you need to bump the version in a Cargo.toml while retaining all formatting and comments.

from cargo-bump.

obliterate the user's Cargo.toml and generate one

As a user this feels like a potentially high price to pay for not much gain. I expect "bump" not "bump-and-reformat".

I bet you could have a regex solution pretty quickly and avoid the warning label. In the context of just "bump" it doesn't even seem that hacky. You're looking for a few specific tokens in a well structured file followed by a simple transformation; classic regex.

from cargo-bump.

package.version isn't the only version = "string" in many Cargo.toml writing an appropriate regex that won't get caught up in comments, strings, wrong sections, and different formatting styles seems like it would be much harder to debug.

Most folks are using git, so if they don't like the results they can just check out the version of their Cargo.toml from before and fix it and then tweet about how the tool is awful.

Rather take the easy way while there are 2 solutions on the horizon rather than take the hard way and burn a bunch of hours to be thrown away in a month or three. Putting the engineering effort into joelself/toml_parser would be a much better investment.

from cargo-bump.

I'm working as fast as I can. This is my #1 project right now. Unfortunately I was going through nom to add some functions and tests as a sort of thank you for providing the package and I found that the string macros (all of which have yet to be released) that I use throughout my parser are written as if bytes == chars (i.e. using functions that return a character offset to index into a byte array). So now I'm going through the str module and fixing everything up and writing tests with all non-ASCII characters to verify everything works with unicode.

Is it going to be a problem that you need nightly rust to compile the library? Because I can very easily scale it back to beta, but going all the way back to stable will take a more significant amount of time and if you need that I'd like to know sooner rather than later. I'm also using, as noted earlier, an unreleased version of nom. I just have it configured to pull from the master branch from github (actually, now that I'm changing it it's pulling from a local directory). If nom doesn't release the str module and my changes by the time I'm ready for my first release I'll just have to pull from my own fork I guess.

from cargo-bump.

@joelself Rad! I hope I wasn't sounding impatient. Was more just excited that someone had recently started working on the problem and was making good progress.

Obviously the wider the version support is ideal, but for my own purposes I don't mind.too much since I use multirust. Beta would be pretty rad since that's likely to be stable soon, but if there is a performance difference I'd understand picking Nightly.

Vendoring nom or pulling from your own fork for a few early releases seems pretty reasonable. Geal seems pretty responsive so I'm sure it won't be for long.

Thanks again for working on toml_parser, I was pretty excited to not have to build one myself!

from cargo-bump.

No, you didn't sound impatient. I just wanted everyone to know that I'm on top of it, but there are a few things slowing me down.

from cargo-bump.