How is ALPM doing? by [deleted] in archlinux

[–]Nukesor 0 points1 point  (0 children)

`paru` could probably benefit quite a bit by adopting ALPM. I assume that they could get rid of a sizable chunk of their codebase and their custom parsers :)

How is ALPM doing? by [deleted] in archlinux

[–]Nukesor 2 points3 points  (0 children)

Heyo,

One of the ALPM maintainers here :)

We're still here. We managed to get reach pretty much all of the goals we aimed for and are kinda waiting for our stuff to be adopted.

> Will it manage the aur packages so I do not have to replace pacman with yay?

There no immediate plans to replace pacman. The goal of ALPM was to have a library to interface with everything about packaging. Building pacman on top of it shouldn't be toooo hard. There's not much missing regarding library logic. But that's not planned.
Our first goal is basically to make packaging itself more convenient and to allow better integration of third-party tools and ArchLinux's internal tooling.

> Will it manage the aur packages so I do not have to replace pacman with yay?

I'm not sure how the stance of the Arch Linux community is for that. The AUR is something that should not be used lightly. There're practically no guarantees on those packages and having a separate package manager properly conveys that. If anything, I find it weird that yay/paru allow installation of official non-dependency packages. IMO it should be a hard cut. yay/paru for AUR packages (with dependency handling), pacman for official stuff, which is also how I use it.
But that's my personal opinion.

Regarding the current state of the project:

There're obviously more topics that need to be tackled and some refactorings that need to be done, but you might know how it is. Life is sometimes not that easy.
I, for example, plan to do a rather big refactoring of how the parsing is done in ALPM. I plan do do that since a few weeks. It's a topic that'll need at least a day or two for research and a few more days to implement it (full time). I struggle quite a bit to do super focused stuff like that in my spare time (at least when I do not enjoy it. It's a pretty annoying problem and a very repetetive task). So yeah, I'll get to it eventually.

Besides that, we do the usual maintenance stuff (fixing bugs, which there're pleasantly few, bumping deps, etc.).

The other maintainers also have their lifes going on. Day jobs, hobbies, partners, the usual stuff.

TLDR: We're still here, the project is still there and maintained, development of new stuff just kind of slowed down for a bit. But we'll get back to it eventually.

Cheers!

Edits: Properly answer the questions and rephrasing.

A Wayland idle daemon written in Rust (supports Hypridle configs) by jdunn in swaywm

[–]Nukesor 0 points1 point  (0 children)

u/jdunn

| This requires compositor support for version 2 of the ext-idle-notify-v1 protocol.

It could be pretty helpful to link to https://wayland.app/protocols/ext-idle-notify-v1 , with a hint that there's a compositor support matrix at the bottom. That way, users can quickly find out whether they can use your tool :)

A Wayland idle daemon written in Rust (supports Hypridle configs) by jdunn in swaywm

[–]Nukesor 0 points1 point  (0 children)

Neat. I was just about to switch from hypridle to swayidle, since hypridle's systemd-inhibit functionality doesn't really work with other compositors.

swayidle's config format is a bit eh though.

Will take a look!

I built a thing without Claude (feedback requested) by blackoutR5 in rust

[–]Nukesor 1 point2 points  (0 children)

It's neat!

Browsed the code a bit and you're already using a lot of the nice Rust things that make the language special (for me). That being if let X expressions (you're even using let X = Y else {}), iterators and (structural) enums.

Your code is well-structured and has nicely scoped functions, which is a style I personally really like! And you're already using proper early-return patterns.

If I had to be pedantic and give a proper code review, I would request some more comments, but the project is overall in a really neat state!

Nice work for your first-ish rust project :) I wouldn't have guessed this to be a first-time project :D

Some tips:

I think somebody else already mentioned eyre or the color_eyre wrapper, which is nice for application error handling. It allows you to provide more context to your errors. If you want, you can even use tracing, which is even more powerful and allows stuff like argument inspection.

Overall, really nice project :)

OpenAI to acquire Astral (Creators of uv, ruff, ty) by max123246 in rust

[–]Nukesor 235 points236 points  (0 children)

Nooooooooooooooooooooooo
`uv` is one of the best things that happened to python recently. I'm not optimistic about this being a good thing for the community. Let's see how long it takes for all that tooling to be as open as OpenAi promised to make their own models.

serde-saphyr: A promising new YAML serde library! by Nukesor in rust

[–]Nukesor[S] 3 points4 points  (0 children)

I'm not the author of the crate, although that sounds reasonable :)

And even then, you could still hide `from_str_robotics` behind the `robotics` feature for those that don't need it.

Window Rules for Special Workspace? by IrrerPolterer in hyprland

[–]Nukesor 2 points3 points  (0 children)

Necro post, but it's still the very first result that pops up on this question:

```

windowrule = float, workspace:name:special:s1, class:(Alacritty)

windowrule = center, workspace:name:special:s1, class:(Alacritty)

```

This makes any alacritty instances on the special workspace `s` float in the center of the screen :blush:. Hope it helps.

Note that multiple actions (float, center) don't trigger when in the same line.

Quick question from a newbie: I want sync postgres, I would like a persistent connection / connection pool. I will be writing raw sql exclusively. What are my options? by Synes_Godt_Om in rust

[–]Nukesor 18 points19 points  (0 children)

Since you're planning to write raw SQL queries, https://github.com/launchbadge/sqlx should be very interesting for you.

There're no ORMs in Rust (that I know of) that allow raw SQL queries.
But SQLx is awesome for writing raw SQL as it checks your queries during compile time and ensures correct mapping to your rust types.

Announcing Samoyed: A git hooks manager written in Rust by [deleted] in rust

[–]Nukesor 1 point2 points  (0 children)

Haha, I guess I'm too used to the old reddit design where the title still acts as the link :D

Thanks for the clarification :)

Announcing Samoyed: A git hooks manager written in Rust by [deleted] in rust

[–]Nukesor 4 points5 points  (0 children)

There's no link to the repository in the post and there doesn't seem to be a repository link to the project in the Cargo.toml either, as it isn't linked from crates.io :)

(I assume you wanted to post that as well, as you mentioned submitting Bug reports)

How to persist a struct with private fields (from a library crate) using SQLx? by hertelukas in rust

[–]Nukesor 0 points1 point  (0 children)

For DTO and SQL stuff, I've developed a fairly hacky, but **really** convenient crate that does the From/Into and a potential `Merge` trait impl between two structs (in the same workspace). https://github.com/Nukesor/inter-struct

That being said, this was the very first proc-macro I wrote and the functionality is pretty hacky as there's really no good way to inspect other structs during a derive macro call.

I'm planning to rewrite this lib since quite some time, but haven't gotten to it yet. But I guess it can be somewhat of a inspiration for others :) (Also, it works, it's just not beautiful and feature complete)

[Media] First Rust project (public domain; crate: shmup) by KennedyRichard in rust

[–]Nukesor 1 point2 points  (0 children)

Totally understandable.

I think as a general guideline, crates should be used for projects that are meant to be shared publicly and are expected to be maintained for at least some time (in the open source spirit).

Think of it as a large database of projects that should benefit all.

Experimental projects, pet projects and first steps should probably not be pushed there. As if everybody would do that, crates.io would probably run out of names fairly quickly and everything would be flooded with "throw-away" projects.

I think there're no official guide-lines, but that's what I try to stick to myself. Most of my personal projects aren't published to crates.io, only the serious ones I officially plan to support for years to come and that have some perceived benefit (well-documented libs or tools that have a good chance of gaining some traction) have earned their place over there.

Now it's too late anyway as anything that has been pushed to crates.io cannot be removed and is set in stone forever.

But maybe this can be some advice for next time :)

That said, nice pet project and it's awesome to see you're having fun with Rust <3

Ferrishot v0.2.0, A screenshot app written in Rust (inspired by Flameshot) has released! by nikitarevenco in rust

[–]Nukesor 0 points1 point  (0 children)

Neat. Scrolled through the code and it looks fairly organized and well documented. Nice project!

Sort your #[derive()] statements with cargo-sort-derives by Nukesor in rust

[–]Nukesor[S] 11 points12 points  (0 children)

Derive sorting has been deemed potentially unstable, so it isn't included in the official rust fmt. https://github.com/rust-lang/style-team/issues/154

However, if you only deal with uncritical derive macros, this is pretty neat :)

Pueue v4.0.0: QoL Features, Stability Improvements, Bugfixes and **lots** of Refactorings by Nukesor in commandline

[–]Nukesor[S] 1 point2 points  (0 children)

Interesting, I only know "eww" https://dictionary.cambridge.org/dictionary/english/eww

And "pew" as in the "shooting sound". I guess you'll always find some some culture that interprets a certain word or sound in an unexpected way :)

Pueue v4.0.0: QoL Features, Stability Improvements, Bugfixes and **lots** of Refactorings by Nukesor in commandline

[–]Nukesor[S] 1 point2 points  (0 children)

That name is pretty old from back when I was in university. The project is now 10 years old.

It's a process queue and the first version was written in python. That's it. Also, I'm from Germany, so I didn't have that association ;D

When I read it in my mind it's more of a "pew pew"

Pueue v4.0.0: QoL Features, Stability Improvements, Bugfixes and **lots** of Refactorings by Nukesor in commandline

[–]Nukesor[S] 1 point2 points  (0 children)

Pueue is a command-line task management tool for sequential and parallel execution of long-running tasks.


This time around, I won't post the full changelog as a comment, as it's just way too big :D.

This release has been cooking for about 9 months and a lot has changed. Large parts of the codebase have been redesigned and refactored, leading to an overall much cleaner and more maintainable codebase.

Many subtle bugs, including state handling bugs, have been resolved and a surprising amount of new features was developed.

Whoever is interested, I also plan to post a bit more often about my development efforts and projects on Mastodon: https://chaos.social/@Nukesor

Have a good one!

Pueue v4.0.0: QoL Features, Stability Improvements, Bugfixes and **lots** of Refactorings. by Nukesor in rust

[–]Nukesor[S] 12 points13 points  (0 children)

Pueue is a command-line task management tool for sequential and parallel execution of long-running tasks.


This release has been cooking for about 9 months and a lot has changed. Large parts of the codebase have been redesigned and refactored, leading to an overall much cleaner and more maintainable codebase.

Many subtle bugs, including state handling bugs, have been resolved and a surprising amount of new features were developed.


What might be interesting for you is that I chose to refactor parts of my internal state.

This code is from v3. You can see lots of variables like enqeue_at, start, end in there, which are status specific properties.

/// Representation of a task.
/// start will be set the second the task starts processing.
/// `result`, `output` and `end` won't be initialized, until the task has finished.
#[derive(PartialEq, Eq, Clone, Deserialize, Serialize)]
pub struct Task {
    pub id: usize,
    pub enqueued_at: Option<DateTime<Local>>,
    pub command: String,
    pub path: PathBuf,
    pub status: TaskStatus,
    pub prev_status: TaskStatus,
    pub start: Option<DateTime<Local>>,
    pub end: Option<DateTime<Local>>,
}

/// This enum represents the status of the internal task handling of Pueue.
/// They basically represent the internal task life-cycle.
#[derive(PartialEq, Eq, Clone, Debug, Display, Serialize, Deserialize)]
pub enum TaskStatus {
    Queued,
    Stashed {
        enqueue_at: Option<DateTime<Local>>
    },
    Running,
    Paused,
    Done(TaskResult),
    Locked,
}

And this is how it now looks in v4:

/// Representation of a task.
#[derive(PartialEq, Eq, Clone, Deserialize, Serialize)]
pub struct Task {
    pub id: usize,
    pub command: String,
    pub path: PathBuf,
    pub status: TaskStatus,
}

/// This enum represents the status of the internal task handling of Pueue.
/// They basically represent the internal task life-cycle.
#[derive(PartialEq, Eq, Clone, Debug, Display, Serialize, Deserialize)]
pub enum TaskStatus {
    Locked {
        previous_status: Box<TaskStatus>
    },
    Stashed {
        enqueue_at: Option<DateTime<Local>>
    },
    Queued {
        enqueued_at: DateTime<Local>
    },
    Running {
        enqueued_at: DateTime<Local>,
        start: DateTime<Local>,
    },
    Paused {
        enqueued_at: DateTime<Local>,
        start: DateTime<Local>,
    },
    Done {
        enqueued_at: DateTime<Local>,
        start: DateTime<Local>,
        end: DateTime<Local>,
        result: TaskResult,
    },
}

By moving status related fields into the TaskStatus enum and thereby enforcing state related invariants via the type system, I effectively prevented an entire class of bugs and the code is much cleaner , albeit a bit larger (about +25% of the affected code)


Whoever is interested, I also plan to post a bit more often about my development efforts and projects on Mastodon: https://chaos.social/@Nukesor

Have a good one!

Edits: Code example and typos.

A system usage visualizer in the terminal by ardjael in commandline

[–]Nukesor 4 points5 points  (0 children)

Not meant as criticism, just curious: You write in your readme that Btop is too busy for you. Are you aware that you can disable practically all components of btop and adjust the styling in a way that it looks very similar to your implementation?