search

LivacoNew / CrabFetch

Extremely fast, featureful and customizable command-line fetcher.
Apache License 2.0
21 stars 4 forks source link

feat: added homebrew package manager #34

Closed FlyinPancake closed 2 months ago

FlyinPancake commented 2 months ago

Closes #32

LivacoNew commented 2 months ago

Was it you on your IDE that caused all these styling changes? Either way, would prefer them to be left at least until I have time to write a style guide for this project.

Also, have yet to install & try homebrew but would like to try to read the actual package data from the Cellar/Caskroom folders, would let version detection be able to query it for speed but will take a look at that myself later if you want

FlyinPancake commented 2 months ago

Sorry, I didn't notice, I had format on save on.

I basically looked at the fastfetch impl and then combined it with the flatpak impl, to get it working.

LivacoNew commented 2 months ago

Ah, I see. Ye FastFetch nor the Flatpak impl get package data, but would be prefered. Again can peep at this later as implementing it can be a bit of a pain

FlyinPancake commented 2 months ago

fixed the formatting :D

FlyinPancake commented 2 months ago

To be frank I don't really feel like reading the source code, but according to my research brew does not maintain a package db

LivacoNew commented 2 months ago

To be frank I don't really feel like reading the source code, but according to my research brew does not maintain a package db

It should cus you can query it apparently

FlyinPancake commented 2 months ago

Qerying takes a long ass time with their stuff

image

gonna dig in some more to see if they are just waking the dirs

FlyinPancake commented 2 months ago

The only thing I am sure about is that Ruby is slow as shit.

LivacoNew commented 2 months ago

I see they have basic name/version info, but nothing beyond that

image

Tried looking through brews source but had a seizure just looking at Ruby code

LivacoNew commented 2 months ago

Yeah, I'm happy with my idea of how to implement this now. Essentially go through the cellar/caskroom and every subdirectory is a package, from there each subdir is the version, which we can just sort alphabetically and select the last entry as at least most of my entries follow major/minor/patch or are just a date.

FlyinPancake commented 2 months ago

Welcome to the Rusticean's Ruby Support Group :laughing:

In the pkgname/version dirs there is a hidden .brew dir, that houses a ruby file that contains the required metadata for ruby. It's a mess...

LivacoNew commented 2 months ago

Welcome to the Rusticean's Ruby Support Group 😆

God help us all

Anyways, you wanna impl this or do you wanna just push this branch and I can do it? Up to you

FlyinPancake commented 2 months ago

I am happy to implement this

FlyinPancake commented 2 months ago

Well I just did some unspeakable crimes with mappnigs...

Added 2ms to the total run >.<

image

LivacoNew commented 2 months ago

Added 2ms to the total run >.<

Not sure I like this, looking at your patch I think it's just cus you call a lot of re-loops. Mind testing with this patch, as I don't have enough packages on my system to make it a performance issue (only 400 microsecs): hopefullyfaster.patch.txt

Just trying to reduce the amount of loops that get ran, although I understand that it's kinda unavoidable to a certain extent

FlyinPancake commented 2 months ago

Ran the patched version a couple of times:

image

LivacoNew commented 2 months ago

How many packages on your system?

LivacoNew commented 2 months ago

Also try to use a tool like hyperfine, as time can only go so far with it I've noticed before

FlyinPancake commented 2 months ago

Good thing I know just a tool to tell me how many packages do I have!

its 158

LivacoNew commented 2 months ago

In that case it's likely just difference in hardware, as i'm only seeing it need 427.911µs on both patches with 78 installed on brew

image

I also only just noticed the 20ms total run time on your screenshots, meaning ye likely just running slower. (Although do please test that FastFetch isn't faster than that, otherwise it's my fault with detections somehow and there's a problem lmao)

FlyinPancake commented 2 months ago

Done some tests with hyperfine

image

LivacoNew commented 2 months ago

Yeah it's fine then, I'll leave my patch to die then cus yours is a bit more concise

FlyinPancake commented 2 months ago

damn, I have a 16 core AMD 3950x and still

FlyinPancake commented 2 months ago

Could we rayon the shit out of the dirs?

LivacoNew commented 2 months ago

Could we rayon the shit out of the dirs?

Don't wanna resort to multithreading just yet, lmao

LivacoNew commented 2 months ago

damn, I have a 16 core AMD 3950x and still

Filesystem overhead then maybe, if you have a sata drive and not a m.2 like I do? Not sure otherwise

LivacoNew commented 2 months ago

Right I'm happy to merge this now, thanks for the pr :)

FlyinPancake commented 2 months ago

Filesystem overhead then maybe, if you have a sata drive and not a m.2 like I do? Not sure otherwise

I'm on an M2 ssd but maybe fedora and a bunch of bg tasks got in the way

Don't wanna resort to multithreading just yet, lmao

Did some tests for my curiosity, the rayon overhead kills it sadly

I'm iffy on the amount of expect calls that are used, I like good error checking, but it's minor and if it causes issues can just modify it later

I only used expects where I already checked the errors previously I believe