feat(datasets): Shorten pyproject.toml extra names for langfuse, opik, and langchain datasets

[ElenaKhaustova]

Description

Context: #1347 (comment)

Development notes

• Removes redundant package-family prefix from dataset-specific extras (e.g. langfuse-langfusepromptdataset → langfuse-promptdataset), making install commands shorter and more consistent with other extras.*
• Meta-extras (langfuse, opik, langchain) are updated to reference the new names. The installed dependencies are unchanged.
• Updates all references in langfuse and opik READMEs to match the new names

Test plan

• pip install kedro-datasets[langfuse-promptdataset] resolves correctly
• pip install kedro-datasets[langfuse] still installs all langfuse deps
• CI passes (no functional code changes)

Developer Certificate of Origin

We need all contributions to comply with the Developer Certificate of Origin (DCO). All commits must be signed off by including a Signed-off-by line in the commit message. See our wiki for guidance.

If your PR is blocked due to unsigned commits, then you must follow the instructions under "Rebase the branch" on the GitHub Checks page for your PR. This will retroactively add the sign-off to all unsigned commits and allow the DCO check to pass.

Checklist

• Opened this PR as a 'Draft Pull Request' if it is work-in-progress
• Updated the documentation to reflect the code changes
• Updated jsonschema/kedro-catalog-X.XX.json if necessary
• Added a description of this change in the relevant RELEASE.md file
• Added tests to cover my changes
• Received approvals from at least half of the TSC (required for adding a new, non-experimental dataset)

[ravi-kumar-pilla]

LGTM

[SajidAlamQB]

Thank you @ElenaKhaustova!

[merelcht]

Much better 👍

[ankatiyar]

The shorter names look good but I'm worried it strays from the convention we have set for the dependencies - the dataset after all is called langchain.LangchainPromptDataset etc. The dependency names are too long but they follow the same standard across all datasets.
These datasets are all experimental of course so maybe this is okay.
When they graduate, we could also consider renaming them opik.OpikPromptDataset & opik.OpikTraceDataset to opik.PromptDataset and opik.TraceDataset but that might be too disruptive for the users who already have adopted them. 🤔 In the case of choosing between renaming datasets or having long dependency names, it would be better to stick with long dependencies in my opinion.
I'm not opposed to this change but just checking if we'll be setting a precedent where the dataset and dependency name might be slightly different and users have to double check in the pyproject.toml here to make sure which one it is!

[ElenaKhaustova]

The shorter names look good but I'm worried it strays from the convention we have set for the dependencies - the dataset after all is called langchain.LangchainPromptDataset etc. The dependency names are too long but they follow the same standard across all datasets.

Yes, that is a valid point, and I think we should also rename langchain.LangchainPromptDataset to langchain.PromptDataset. The problem is that if we go ahead with this for the already-released datasets we will probably need to add the short name as an alias with a deprecation warning on the old name. For example, from kedro_datasets_experimental.langfuse import PromptDataset works, and LangfusePromptDataset still works but logs a deprecation. To give users a migration window.

And I see the following pros for renaming:

• shorter names for dependencies
• langfuse.EvaluationDataset is arguably clearer than langfuse.LangfuseEvaluationDataset since the package already tells you it's Langfuse.
• It also matches how the core LangChain datasets work — langchain.ChatOpenAIDataset, not langchain.LangChainChatOpenAIDataset.

So we probably should either rename both dependencies and datasets or leave them as is. My question: do you think it's worth it? @merelcht, @ankatiyar

[ankatiyar]

Ideally I also like the dataset names to be langfuse.PromptDataset and langfuse.TraceDataset (similarly for opik etc) , then the dependency names could also be short and follow all convention. We have precedent for this as well with various CSVDataset/JSONDataset/ParquetDatasets (pandas and dask). We also have some datasets that repeat the package name (svmlight.SVMLightDataset, netcdf.NetCDFDataset)

Since these are experimental datasets, we could update the names (with or without a deprecation warning, but for user experience aliasing might be good). We would also have to update the projects in kedro-academy, the starter and maybe blog posts? We can do it now (while they're still experimental and maybe not many people use it in the wild) or when we consider graduating them (people will have to migrate anyway, could rename datasets at the same time).
However, if we're not updating the names, maybe we could stick with the longer dependencies for now? Will defer to @merelcht's judgement

[merelcht]

I was thinking about this too, thanks for raising it @ankatiyar. I think we should take the benefit of these being experimental and just doing the rename without a transition period. Normally I would definitely be against that, but the whole point of these being experimental is that we're allowing slightly less solid datasets to be released and therefore breaking changes can happen while polishing the datasets between releases.

As an extra check we can have a look at telemetry to see if many people are using these datasets and make a decision based on that if we see adoption is already high.

[ElenaKhaustova]

We had a discussion with @merelcht and decided to do the full renaming, but hold it until #1364 is completed