Not having used uv but being on the Cargo team for Rust, I wish `cargo update` was `cargo lock update` because it is making our life more difficult to add a version requirement update command/mode inside of Cargo. The effort has been stalled for years.
- Our compatibility guarantees mean we can't fundamentally change `cargo update`
- Using the third-party package name of `cargo upgrade` would be confusing in the distinction between the two
- We have to be very careful adding the mode to the existing command
An important part to me that gets overlooked is shared logins. Rust runs the tests of all known Rust projects in a tool called `crater`. I was analyzing a run identifying projects relying on internals of Cargo and opening issues. When making 200 issues by hand, it is a big help when the process is low friction: I had credentials for the site and allowing blank templates. Any time I came across a self-hosted instance, I usually ended up giving up.
This is something federation could help with: you would be able to use your account on, say, Codeberg to make issues on all self-hosted instances. Sadly, it’s still not in a great shape: https://forgefed.org/
(As a fallback, why not email the maintainers instead?)
I appreciate you recognize there is still a reason for grouping commits into mergeable units (PRs). Some go too far and only want every commit to be independent.
I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed.
I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis.
There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.
Yeah, having `cargo test` require another binary like `uv` is not idiomatic. 99% of the time, I should be able to walk up to a Rust project and run `cargo test` and it should just work.
Really interested in this for cargo/rustc. We run into issues where we need one or two more colors but all that is left after going for the basic semantic colors is magenta (odd choice), and black and white (not safe without inspecting the theme).
Other than red and green, for semantic reasons, a CLI tools shouldn’t bother with colors. And it should support text markers instead of colors for the occasional piping.
That's what cargo/rustc do: all of the information is conveyed through text, but colors are used to make it easier to scan. It ends up using almost every usable base-16 color: red for the error marker and their primary spans, yellow for warnings and their primary spans, blue for secondary spans, the gutter separator and line numbers, bold text for the main message, cyan for notes and their primary spans, green for helps and their primary spans, green and red for structured suggestions, bright magenta for very specific hand-picked highlights (used to be bold/bright white, but that wasn't obvious enough in lots of terminals, used semantically equivalent to bold or italics in text, the case most people will encounter these in is in E0308 type errors where a specific type parameter didn't match) and white for anything else. Note that of the mentioned output the only thing that is differentiated in color only is the message highlights, and that's because it is generally done for either extra clarification ("Trait is not implemented for Foo, but it is implemented for Bar") or within code that we wouldn't want to pollute with additional non-code ASCII markers (people should be able to copy&paste those types without causing parse errors). Some people deride this variety as being too "christmas tree", but IMO it works quite well for scanning output. Color helps a lot when scanning longer lists and dense output. Colors might not help much if the tool is emitting a single line of output for each event, but rustc emits dozens of lines per error. And no, reducing the amount of output would not be the answer for rustc, you can already use `--message-format=short` if you want that, or try/contribute to one of the TUI projects consuming the json output for dynamic navigation of the output (to expand and contract sections). rustc and cargo default configuration have to cater to the most common case, while also keeping the number of non-essential features (like a built-in TUI) to a minimum.
For me the issue isn't performance but bad hook updating logic. They expect hooks to be managed in isolated repos with exclusive use of tags. I have my gh action and hook in the repo of my program and it has been a source of pain to users but I'd rather drop pre-commit support than have to deal with update across repos. prek fixed this.
- splitting up a package into smaller compilation units to speed up builds as llvm doesn't like large compilation units, e.g. I'm assuming this is why uv is split up
- splitting semver concerns (easiest if different parts of the api are versioned independently), e.g. one hope for splitting out `serde_core` is to allow breaking changes of `serde_derive`
- splitting out optional parts to improve build time (`features` can also be used but usability isn't as great), e.g. `clap` (cli parser) and `clap_complete` (completion support)
- less commonly run tests or benches that have expensive dependencies, e.g. `toml` splits out a benchmark package for comparing performance of `toml`, `toml_edit`, an old version of `toml`, and `serde_json`
- proc-macros generally have a regular library they generate code against
- lower development overhead to develop them together, e.g. anstyle has a lot of related packages and I wouldn't be wanting to maintain a repo per package
Something this doesn't mention is that Cargo workspaces allow for sharing parts of the manifest through "workspace inheritance", including package metadata like the repo, dependency version requirements, lint configuration, or compilation profiles.
> In fact, a code fence need not consist of exactly three backticks or tildes. Any number of backticks or tildes is allowed, as long as that number is at least three
Unfortunately, some markdown implementations don't handle this well. We were looking at using code-fence like syntax in Rust and we were worried about people knowing how to embed it in markdown code fences but bad implementations was the ultimate deal breaker. We switched to `---` instead, making basic cases look like yaml stream separators which are used for frontmatter.
Yeap, along with `+++`, `**` and mixing if I remember correctly.
I don't understand the logic of using an non-standard syntax because some non-standard implementations may not render correctly.
Actually, yes, now you know for a fact that none of the Markdown implementation will render it correctly.
So, I guess, they used `~~~` instead and it was an error in OP post.
The problem here is that if you use ``` as a token in a non-markdown language, then it's going to be very hard to embed that code in a markdown code block. That problem doesn't happen with other syntax as it's already escaped by the code block. `---` inside a markdown code block will render as a literal `---`.
For new implementations, sure. But it's harder to change existing implementations (anything not already CommonMark-compatible will introduce unexpected changes to existing content if you switch to CommonMark), and especially for anything that's not being actively developed it's unlikely to ever change.
> Use hand-written parser
>
> The old parser was written with winnow which is a parser combinator library.
While it’s easy to create a parser with parser combinators, it’s generally slower than a hand-written parser,
so the first step is to write the parser by hands. Hand-written parser is not only faster but also allows to do more optimizations in the future.
Maintainer of Winnow here. I wish there were more details on this. I switched `toml` / `toml_edit` to being hand written and got some performance boost but I feel like the other things listed would have dwarfed the gains that I got. I wonder if there were sub optimal patterns they employeed that we could find ways to help better guide people.
For anyone going on about "hand written is always better", I disagree. Parser combinators offer a great way to map things back to grammar definitions which makes them much easier to maintainer. Only in extreme circumstances of features and/or performance does it seem worth going hand-written to me.
> "hand written is always better", I disagree.
- Yep. As far as I know, winnow provides SIMD in some cases, while for hand written parsers, writing SIMD can be very hard.
- completions being aware of previous options, flags, and values
A lot of completions have the first. Some have the second. The last is rare. The completer needs knowledge of when flags, options, and value can be repeated and change which future options and values are suggested.
- Our compatibility guarantees mean we can't fundamentally change `cargo update`
- Using the third-party package name of `cargo upgrade` would be confusing in the distinction between the two
- We have to be very careful adding the mode to the existing command
reply