Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming things #4

Open
amotl opened this issue Dec 11, 2023 · 2 comments
Open

Naming things #4

amotl opened this issue Dec 11, 2023 · 2 comments

Comments

@amotl
Copy link
Contributor

amotl commented Dec 11, 2023

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 23, 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 14. 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.

Footnotes

  1. https://github.com/crate-workbench/meltano-tap-cratedb 2

  2. https://github.com/MeltanoLabs/tap-postgres

  3. https://github.com/MeltanoLabs/target-postgres

  4. https://github.com/crate-workbench/meltano-target-cratedb

@pnadolny13
Copy link

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
Copy link
Contributor Author

amotl commented Dec 12, 2023

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.

Footnotes

  1. https://github.com/meltano/sdk/tree/main/singer_sdk

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants