Support for fetching remote repositories

[gbaranski]

Hello, what do you think about that? Command for that could look like that

onefetch --github o2sh/onefetch

Or instead --github, --remote

onefetch --remote o2sh/onefetch

[HallerPatrick]

Would the remote repo then be cloned beforehand? And if yes, in a temporary folder or at the current working directory?

onefetch already uses git2, which also supports cloning, so the implementation would be easy. Would love to help out with this.

[gbaranski]

Would the remote repo then be cloned beforehand? And if yes, in a temporary folder or at the current working directory?

onefetch already uses git2, which also supports cloning, so the implementation would be easy. Would love to help out with this.

Yes, it would be cloned, on unix systems we can use /tmp for storing the repository, no idea how to do that for windows.

[HallerPatrick]

Would the remote repo then be cloned beforehand? And if yes, in a temporary folder or at the current working directory?
onefetch already uses git2, which also supports cloning, so the implementation would be easy. Would love to help out with this.

Yes, it would be cloned, on unix systems we can use /tmp for storing the repository, no idea how to do that for windows.

I think windows uses %localappdata%\Temp. Not really sure tho. Would the git repo afterwards be deleted? And if not, would a new onefetch --remote <same-repo> clone it again into temp or use the existing one?

[gbaranski]

Would the remote repo then be cloned beforehand? And if yes, in a temporary folder or at the current working directory?
onefetch already uses git2, which also supports cloning, so the implementation would be easy. Would love to help out with this.

Yes, it would be cloned, on unix systems we can use /tmp for storing the repository, no idea how to do that for windows.

I think windows uses %localappdata%\Temp. Not really sure tho. Would the git repo afterwards be deleted? And if not, would a new onefetch --remote <same-repo> clone it again into temp or use the existing one?

On Linux /tmp directory is stored in RAM, so that should be deleted automatically after restart. On windows, no idea. I've used https://doc.rust-lang.org/std/env/fn.temp_dir.html for retrieving temp directory.

That's how it works now

[spenserblack]

You may also want to look into the temp-dir crate or tempfile crate, which provide a struct that will delete the directory's contents when it is dropped.

[spenserblack]

I'm going to have to think about this feature a bit. It sounds cool, but I wonder if it's worth it when the user can just

1. git clone <my-url> <my-dir>
2. onefetch <my-dir>
3. rm -rf <my-dir> (if necessary)

[GameKyuubi]

Is it absolutely necessary to clone the whole repo to get the data? Would it be impossible to get the data directly from github or smth?

[spenserblack]

Without cloning, much of the info would still be available via the GitHub API. But it's been discussed a few times if onefetch should fetch data from the API, and concluded that onefetch should be an offline-only tool.

See #24 (comment), #63 (comment), and #351 (comment)

[GameKyuubi]

Perhaps, since it already supports exporting JSON, it could also import JSON, so that it could be used in a chain with a program that does all that data collection separately?

[spenserblack]

Honestly, if onefetch was going to give that level of ability to define your own statistics, it would probably be through more command-line options instead of consuming JSON. The main reason would be to prevent duplication of efforts by supporting stats via flags and JSON input.

If onefetch consumed JSON, it would almost be better design to split onefetch into multiple tools IMO. A tool that generates standardized JSON from GH API, a tool that generates standardized JSON from local repo, and a "front end" that consumed the data for pretty terminal output. Which sounds fun, but should be a new project instead of a change to onefetch IMO.

I think that, mainly, @o2sh created onefetch to be "neofetch for your repo." He can clarify more on the intent, but I think anything beyond more command flags is considered out of scope.