Creation of a generic llm-tools repository

[skissue]

Hello @ahyatt,

I'm considering creating a simple, generic llm-tools repository just to get things going on having a model collection of tools capable of being plugged in to both gptel and llm (and perhaps more in the future). @karthink recommended that I check with you first on the usage of the namespace before creating a repo. Unfortunately, I don't have the FSF paperwork completed; I can look into filling it out. Would you be okay with me using the llm- namespace regardless? If not, I can use a different name instead.

See karthink/gptel#514 (comment) for more context.

[ahyatt]

I think llm-tools is a bit confusing, since my llm package has tool capability already. Perhaps calling it llm-tool-collection would help users understand this is a collection of tools, not a package to enable llm tool use. I think it'd be nice to have it further distinguish itself from the llm package, but I'm struggling to come up with a better name.

I don't believe you'll need FSF paperwork unless you want this as part of GNU ELPA. There's some advantage to being part of GNU ELPA; you get users who will only want to use code assigned to the FSF. However, it would hinder your ability to accept contributions, which seems important for this kind of package.

[skissue]

I think llm-tools is a bit confusing, since my llm package has tool capability already. Perhaps calling it llm-tool-collection would help users understand this is a collection of tools, not a package to enable llm tool use. I think it'd be nice to have it further distinguish itself from the llm package, but I'm struggling to come up with a better name.

That's a good point. I like llm-tool-collection as well. The only other idea I have would be to call it tool-collection, but that seems far too ambiguous. I'm going to proceed with llm-tool-collection as the name for now.

I don't believe you'll need FSF paperwork unless you want this as part of GNU ELPA. There's some advantage to being part of GNU ELPA; you get users who will only want to use code assigned to the FSF. However, it would hinder your ability to accept contributions, which seems important for this kind of package.

Yes, that was also brought up by @karthink; a crowdsourced collection should be able to accept contributions as freely as possible, and requiring copyright assignment would make that difficult.