Snippet repository

[amosbird]

Hi, thanks for this great tool. I was thinking the similar thing before finding it. However I feel a strong need to have a central snippet repository so that we could be more productive and learn cool one liners from community. Is there already some existing? What do you think? 😄

[knqyf263]

@amosbird I'm sorry for my late reply.
I think so, too. However, It is hard to manage a central server, so I'm thinking about a good way to do it.
Is it better to create a repository for snippet management in Github?
Please tell me if you have any good ideas!

[amosbird]

IMHO, we could have a dedicated github repo for snippets, and customize pet sync command to support official snippet repository as well as private ones. We may also need to smooth the workflow of snippet contribution.

[fprimex]

I would really like to see a good way to share snippets as well, to encourage sharing among groups. I think this could be (more) easily accomplished by supporting multiple directories of snippet files, along with git repos, such that one could clone into the snippet directory in order to combine them all into the full snippet library.

Then the distribution model is just git, no registry or server code needs to be written. Is this dumb? I'm not very familiar with pets internals.

[nogweii]

Having a git repository full of .toml files and pet supporting reading a directory instead of just a single file could handle this.

[mikenicholson]

Another useful feature would be the ability to specify multiple git repositories as data stores.

For the majority of users, one git repo would probably be enough. However, I'd really like the ability to keep general Linux snippets that are broadly applicable synced to a public GitHub repo across my work and home machines, while still being able to store work-specific snippets in a private Git repo.

Are you open to PR's implementing the basics of using a directory (or directories) of flat files as the storage mechanism for pet? Git operations could be added once the directory-backed storage is implemented.

[pintergreg]

I like the idea of multiple git repository, thus I can have a private storage and also I can use the sheared snippets. With git the change tracking is also solved.

[sbrl]

I've just moved ~/.config/pet to my bin folder, which is already under git, and left behind a symlink.

It works well enough as a workaround :-)

[QasimK]

GitHub already functions as a public repository for snippets: https://gist.github.com/search?l=TOML&q=filename%3Apet-snippet.toml. It isn't great, but it is a starting point for anyone looking for one-liners right now, like me 😄

This also allows you to search for specific tools, for example if you are looking for one-liners involving exiftool.

[sbrl]

Yeah. I'm using Lepton as a gist client at the moment for snippets, and the hstr favourites for bash one-liners. pet just hasn't worked out for me because a) I've got to have a different binary for each cpu architecture and b) it doesn't yet support armv7 (Raspberry Pi).

[cocobear]

is there has been any progress on the issue ?

[helmecke]

I have added multiple file and multi folder support and opened a merge request. See #121

[RamiAwar]

I love the idea of a central repository that pet automatically pulls from, but can imagine it will be extremely difficult to pull of.

1. In terms of contributing to that snippet repo, very hard to test out all kinds of snippets for all kinds of things. Contributions will probably have to be accepted without testing them. --> This can be solved by adding the user's profile to the snippet URL or something. But this kind of negates the purpose? Might as well host that snippet in the user's repo.

2. We'll also need a way to 'discover' snippets and properly tag them. Finding the right snippet you need is going to be hard, descriptions might not be specific enough or overlapping.

3. Will easily become a source for malicious scripts 😈 that are very well-written and hard to detect. I'm no security expert but even security experts will be struggling hard with everything that keeps coming up.

4. Will quickly be filled with snippets that are broken; a lot of times things that work on our machines work because of dependencies we're not aware of.

If you can help find solutions to all of these then we can do this 😅

I like @helmecke 's approach, give power to the user, can specify multiple places to pull from. Is still increasing attack surface but at least we wouldn't be responsible for it?

[Vaisakhkm2625]

actually, what other similar projects like intellishell, marker does is, use tldr as a snippet sharing platform...

it's already contains a lot of useful snippets and people always share it, and has support of multiple languages...
but in that case pet needs to be able to convert back and forth from it's snippet format...

[RamiAwar]

@Vaisakhkm2625 That is so interesting... Thanks for sharing! Haven't heard of it until now. I think we can definitely support that if people are interested in having it as an extra source.

I think this can also be designed to be generic so as to support multiple such sources with a "sync" command. Each would have it's own data fetching method + serialization into pet format.

I like this now, builds on top of @helmecke 's suggestion while still meeting the need for an optional 'central repository'.

[Vaisakhkm2625]

@RamiAwar

Actually, i already made a quick python script for converting all of those into a format pet understands, (thanks to intelisense project, i jist converted their rust code to python, and changed the regex to match pet's).
https://github.com/Vaisakhkm2625/pet-tldr-snippet-maker

It generated over 60k snippets, 😕 and pet search taking 7-8 sec to search it in my laptop

and searchs are itself unusable in fzf, as it is not key word based search, but rather fuzzy search that keeps order

[Vaisakhkm2625]

😅 actually my computer is in a terrible state rn... i will show the perf difference between pet and intellishell as a video
i really love the concept of pet and wanted to use this instread of intellishell, but can't can't do with that much perf difference....

so a pre-load/caching mechanism would be nice, along with mulit files support, which all i hope some people have raised issues

[Vaisakhkm2625]

2024-02-27.04-12-12.mp4

now that i tested it again, it's fine... tough i should try changing fzf for something else... in this case, such a central repository make sense...

[RamiAwar]

Wow that's pretty good! @Vaisakhkm2625 Not slow at all 😄