What about adding a "Description" info line 🤔

[o2sh]

For rust projects, we could parse the description entry of the Cargo.toml file and display it - if present - as an additional info line:

We'll have to be careful with the description's length, maybe by adding break lines or truncate it - and add ... at the end - if it exceeds a certain length 🤔

Bonus: We could also add a cli flag to allow the user to customize it and provide their own description.

[spenserblack]

Some other package managers (just off the top of my head for now):

• package.json: description
• foo.gemspec: This one is a bit tricky, since it's code, not a data file, but spec.description = "<description>"
• setup.cfg: metadata.description
• pyproject.toml: tool.poetry.description"

Also, addressing #832 (comment), if we're already reading a package manager's manifest files, then most of them should have a name field, which might be more accurate than the name in the remote. For example, the repo might be called foo-rs, while Cargo.toml's name is foo.

Maybe we should honestly write a separate crate for this: just like we use tokei to read language stats, a crate like project-info to detect and read manifest files. Because this could be a lot to put into onefetch. Maybe there's already a crate for this 🤔

[o2sh]

Maybe we should honestly write a separate crate for this: just like we use tokei to read language stats, a crate like project-info to detect and read manifest files. Because this could be a lot to put into onefetch. Maybe there's already a crate for this 🤔

That's right, besides, we already have a good basis with the DependencyDetector, we "just" need to extract more data - name and description - out of the manifest files.

For reference, I found cargo_toml for Cargo.toml, npm-package-json for parsing package.json, but no crate that is general purpose (handles multiple package manifests) like we need.

[spenserblack]

but no crate that is general purpose (handles multiple package manifests) like we need.

We might need to write our own crate. TBH right now I've overextended myself with too many pending personal projects right now 😆, but I'd be happy to write such a crate eventually. Would it make sense to create a onefetch GitHub org to collect multiple repos together?

Right now I'm thinking that such a library would recursively read from a given directory (taking .gitignores into consideration), and return the manifest and its path. The exact data structure pending, but something like this

struct Manifest {
    manifest_type: ManifestType,
    path: Path,
}

enum ManifestType {
    Npm {
        name: String,
        description: String,
    },
    Crate {
        name: String,
        description: String,
    }
}

pub fn get_manifests<P: AsRef<Path>>(path: P) -> Vec<Manifest> {
    // ...
}

Multiple manifests would have to be returned to handle monorepos. For our uses we would only probably use manifests in the root path.

[o2sh]

TBH right now I've overextended myself with too many pending personal projects right now 😆

Sounds like you're having fun 😅.

Would it make sense to create a onefetch GitHub org to collect multiple repos together?

If I'm not mistaken GH org are not eligible for Vercel free tier. Maybe, we could do it like gitoxide (or gitui) and have multiple crates living in the same repo 🤔

Multiple manifests would have to be returned to handle monorepos. For our uses we would only probably use manifests in the root path.

Agreed, We can stick to root's manifest 👍

[spenserblack]

If I'm not mistaken GH org are not eligible for Vercel free tier

Ah, good point. We could possibly have o2sh/onefetch for the main project, and onefetch/foo for supporting crates (I should mention that I've been entertaining the idea of forking tokei and making a new crate for our purposes 😆, so that's another crate under the onefetch namespace). But that could be overkill. Like you said, converting this repo into a crate workspace might be best. I think it's less a question of code organization and more a question of

• integration payment plans, as you've mentioned
• permissions (e.g. a collaborator for crate foo but not crate bar)