search

crate-workbench / meltano-target-cratedb

A Singer target / Meltano loader for CrateDB, built with the Meltano SDK, and based on the Meltano PostgreSQL target.
MIT License
0 stars 0 forks source link

Naming things #4

Open amotl opened 11 months ago

amotl commented 11 months ago

Dear @edgarrmondragon, @visch, @sebastianswms, and @pnadolny13,

thank you for your interest and for subscribing to the other repository ^1 about data connectors of CrateDB to the Singer/Meltano ecosystem, and thanks to you and your colleagues for the hard work you are putting into the MeltanoLabs variants of {tap,target}-postgres ^3, so that it was easy for us to build upon, in order to contribute another pair of source/sink data processing elements for the database we are conceiving.

About the "naming things" aspect, I wasn't sure: {tap,target}-cratedb was a bit too short for my taste, so I added a meltano- prefix ^1. Please let me know if this is not appropriate because of branding matters. Would using the singer- name/prefix be more appropriate? We are humbly asking to guide us properly, because we are still newcomers to the Singer/Meltano ecosystem.

With kind regards, Andreas.

pnadolny13 commented 11 months ago

thank you for your interest and for...

😄 we're happy to help!

About the "naming things" aspect, I wasn't sure: {tap,target}-cratedb was a bit too short for my taste, so I added a meltano- prefix

@amotl it up to you to name the repo what you'd like but tap-{name} is the convention of the Singer ecosystem and is what we'd recommend. We see some connectors with meltano- prefixes but on the hub we actually list them without the prefix for various reasons but one major one is because commonly theres multiple connector variants for the same source so we rename them to group them more clearly. Theres a few exceptions to this rule though. Also even though most people will use the connectors with Meltano they arent specific to Meltano but rather to Singer.

amotl commented 11 months ago

Hi,

thanks a stack for your response.

We see some connectors with meltano- prefixes but on the hub we actually list them without the prefix for various reasons.

Ah, I had such a feeling when conducting some searches there, and then advancing to the corresponding Git repositories. Thanks for clarifying.

Also even though most people will use the connectors with Meltano they arent specific to Meltano but rather to Singer.

That's true. Initially, I thought I'd use the meltano- prefix because it would use the Meltano SDK instead of the Singer SDK, in order to give appropriate credits. Now that I discovered in the meanwhile, that the latter actually has been folded into the former ^1, I see that making this distinction may not be appropriate/needed.

Also, I have been coming from a repository naming perspective: On github/meltano or github/meltanolabs, it feels natural to go along with just tap-/target-. However, on our org, I wanted to use a dedicated prefix to designate the repositories correspondingly.

I think the right decision, also taking the heuristics into consideration you are employing on the hub, would be to publish PyPI packages without any prefix, as you recommend. On our GitHub org though, the repository itself can have a different name, in order to reduce ambiguity, and to have a stable sort order, also on local filesystems [^2] ;].

So, I will prune the existing packages from PyPI, and re-upload them using different names without a prefix. On the repository name, we could switch to singer-, but I think the meltano- label can also need a higher circulation, so I will be happy to keep the repository names, and I am happy you don't have any objections about it.

Thanks again, and with kind regards, Andreas.

[^2]: Apologies for my pedantry here, but we also need to optimize our integrations for developer efficiency, because, well, lack of resources everywhere ;].