mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Serverstatistik:

1,5 Tsd.
aktive Profile

#cargo

4 Beiträge3 Beteiligte0 Beiträge heute

💖PLAY NOW💖
👉mokiru.com/games/4wd-off-road-

What game is this?👇
Test and further develop your driving on the web with six distinct sorts of trucks, jeeps, and vans. Begin with more modest and less strong SUVs, the old Land Rover, and afterward the new better, and worked on 4x4 vehicles. Investigate testing backwoods all-wheel-drive streets and follow the sloppy streets to the blue waypoint circle.#truck #forest #cargo #transport #offroad #Racing #Driving #freegames #instantgames #browsergames #nodownload #SimRacing #car #carsimulator

Just found out that #cargo (The #rust thing) is still pre-release software at version 0.88.0…

Kinda not surprising considering that even their
#semver implementation isn’t standards-complient and assumes any form of stability guarantees for pre 1.0.0 releases. Sadly it still drives home that the rust ecosystem as a whole is still not ready for actual practical use, because everything seems to depend on unstable pre-release versions.

(Seriously, this
#zerover nonsense is a much bigger factor in keeping me away from rust than it probably should be; among many other issues it communicates an extreme disregard for standards and professionalism: Semver explicitly states that “If your software is being used in production, it should probably already be 1.0.0.” — Having widely used software on version 0.x.y is at least as much a semver-violation as a minor breaking change between version 1.1.1 and 1.1.2! Rewriting with a new API in a different programming language between version 0.2.3 and 0.2.4 is btw. NOT a semver-violation, but explicitly allowed!)

Ok, I want to run Hadron, which means I need to compile Hadron which means I need a Rust toolchain which means I need something called cargo which means I need something called cargo-features = ["edition2024"]

Which seems to be too new for ubuntu apt packages....

Or perhaps I've misunderstood?

#SuperCollider#Hadron#Rust

Just ran into an interesting #cargo #rustlang workflow problem, that I am not sure how it is best avoided?

A project I work on is depending on strum and strum_macros. Due to a cargo update multiple strum versions now got unified, and only a single version is built. That's good.

A dependency I was using had a pattern as such:

use strum::EnumMessage;
use strum_macros::EnumMessage;

Which is totally fine!

With the unification, the features now also got unified. Which in this case meant that EnumMessage is now present in the macro-scope in both strum and strum_macros.

Which means the above two lines cause an error with EnumMessage being imported twice! Fun.

So the situation is that strum is fine, as it is an additive feature. And the dependency is fine as well, as it itself doesn't use the 'derive' feature.

Another reason why this happens seems to be because we are using cargo-hakari to have less cache-misses in our workspace. But once our workspace-hack crate added the derive feature it broke the build.

The final piece seems that a transitive dependency both:

  • Had the derive feature of strum enabled
  • Did a 0.x.y release (aka minor? patch?) that had a major update of its dependencies in it. (i.e. 0.26 -> 0.27)
  • Is a proc-macro ? (potentially irrelevant, potentially the missing piece)

So to me the full reproduction would be:

  • Have a dependency tree that contains both foo v0.1 (derive feature) and foo v0.2 (no features)
  • cargo update
  • It still builds
  • cargo hakari adds for both 'normal' deps and 'build' deps foo v0.2 (derive feature)
  • This causes cargo to unify foo for both normal builds and proc-macro builds
  • The build fails due to duplicate entries

It feels like the use of cargo-hakari caused this situation, as without it, it would have been fine I guess? But adding a feature flag, shouldn't break downstream crates either 😿 so bleh

#dailyreport #tokenizers #huggingface #rust #gentoo
#ebuild #secops #cargo
I compiled the HF 🤗 tokenizers library from sources and
enhanced Gentoo ebuild file to allow reproducible
installation from sources.
I removed optional dependencies and disabled HTTP
requirements to enhance security.

I wrote very simple tests for tokenizers, safetensors,
transformers and integration test for them, because
tokenizers require HF hub for testing, that I disabled.

It was a hard but good experience with Cargo package
manager of Rust. The main problems was due to strange
cfg flags that Gentoo should have set automaticly, for
ex. target_os=linux was not set. "cfg" is an
abomination that you can't add change this safely.

I didn't find a working solution to manage "cfg" and, so
I just patched the Cargo.toml files of dependencies by
commenting out lines.
(∠・ω )⌒

#dailyreport #tokenizers #huggingface #rust #gentoo
#ebuild #secops #cargo
I compiled the HF 🤗 tokenizers library from sources and
enhanced Gentoo ebuild file to allow reproducible
installation from sources.
I removed optional dependencies and disabled HTT
requirements to enhance security.

I wrote very simple tests for tokenizers, safetensors,
transformers and integration test for them.

It was a hard but good experience with Cargo package
manager of Rust. The main problems was due to strange
cfg flags that Gentoo should have set automaticly, for
ex. target_os=linux was not set. "cfg" is an
abomination that you can't add change this safely.

I didn't find a working solution to manage "cfg" and, so
I just patched the Cargo.toml files of dependencies by
commenting out lines.
(∠・ω )⌒

#dailyreport #tokenizers #huggingface #rust #gentoo
#ebuild #secops #cargo
I compiled HF tokenizers library from sources and
enhanced Gentoo ebuild file that allow reproducable
installation from sources.
I removed optional dependencies and disabled http
requirements to enhance security.

I wrote very simple tests for tokenizers, safetensors,
transformers and integration test for them.

It was hard but good experience with Cargo package
manager of Rust. Main problems was because of strange
cfg flags that Gentoo should set automaticly:
target_os=linux was not set. "cfg" is an abomination you
can't add change this safely.

I didn't found working solution to manage "cfg" and just
patched Cargo.toml files of dependencies. by commenting
lines.
(∠・ω )⌒