[MNT] Migrate from ydata-profiling to fg-data-profiling

[amotl]

About

Migrate from ydata-profiling to fg-data-profiling.

Details

ydata-profiling is now fg-data-profiling. This package has been renamed to fg-data-profiling. Please follow the Migration Guide as soon as possible — the old package will no longer receive updates or bug fixes.

[fkiraly]

I think we should investigate briefly what exactly happened there before deciding on a fork.

If the package has changed maintainers, why did it have to get renamed?

[amotl]

Hi. I think it isn't a fork, but a transition instead. The GitHub project URL https://github.com/ydataai/ydata-profiling redirects to https://github.com/Data-Centric-AI-Community/fg-data-profiling.

[fkiraly]

that does not add up. Why did the pypi name get changed? That is one of the worst things you can do to your users, so a project in transition would normally not do that - one does this only if one has no other choice.

[amotl]

I think there are many reasons to do it anyway you like, not all other projects can act or want to act on fundamental principles close to yours. There are many ways to deviate, and they don't necessarily become wrong only because they are different. Please tame your judgement.

[amotl]

ingestr was friendly-forked to omniload, pycaret was friendly-forked to pycaret-core, and skbase was also somehow renamed or forked to scikit-base, like sklearn to scikit-learn? For me it looks like renaming a package is not so rare at all, while of course I agree it is always unfortunate.

[fkiraly]

Please tame your judgement.

I am not making a judgment at all. All I am saying that we need to have a better picture about what is going on there.

I have zero information, so I am not alleging anything or judging anything.

skbase was also somehow renamed or forked to scikit-base

Initially, we reserved both names, like scikit-learn also reserved sklearn. We discontinued skbase, just like scikit-learn discontinued sklearn (as pypi package names), no fork there,

[amotl]

I guess it was also a discontinuation of the former package. Maybe @portellaa knows more, as he implemented the rename with Data-Centric-AI-Community/fg-data-profiling@628d400 the other day? On the other hand, maybe they might not be able to share the exact reasons, so this might easily fall into the "no other choice" category. ;]

[amotl]

That's the official name change announcement on both project's PyPI landing pages.

Project details are also identical.

-- https://pypi.org/project/ydata-profiling/
-- https://pypi.org/project/fg-data-profiling/

[amotl]

@fkiraly: In this spirit, I think the update is legit. Have you been able to find more information, or do you need more information before proceeding, or do you think I am evaluating and handling this too light-heartedly?

[amotl]

It looks like the grant to YData expired on 31-12-2025, and their GitHub doesn't show any activity since March 2026.

-- https://ydata.ai/responsible-ai.html
-- https://github.com/orgs/ydataai/repositories
-- https://ydata.ai/hubfs/6266199/Website/ficha_modelo-2024.11.26.pdf

It looks like DCAI is trying to keep up maintenance of a few YData packages.

-- GitHub: https://github.com/Data-Centric-AI-Community
-- Discord: https://tiny.ydata.ai/dcai-community-github

What is unfortunate is that their website seems to have been hijacked by casino people. We should tell them. We just told them on Discord and GitHub.

• datacentricai.community hijacked Data-Centric-AI-Community/awesome-data-centric-ai#22

[amotl]

The new fg- package prefix is probably coming from the names of the original authors Fabiana Clemente and Gonçalo Martins Ribeiro, see ydata-profiling paper? /cc @fabclmnt, @gmartinsribeiro

[amotl]

YData was acquired by KPMG in October, 2025.

• https://englandco.com/ydata-agrees-to-be-acquired-by-kpmg-us/
• https://kpmg.com/us/en/media/news/kpmg-accelerates-ai-strategy-with-ydata.html

[fkiraly]

This sounds odd. I would really like an explanation what is going on here.

In particular, since in the past, some of our packages at GC.OS have also experienced an destruction attempt where the pypi account was taken over and it started directing to a fake fork. The perpetrators attempted to publish a package that says "this package is defunct, now download xyz instead".

It may well be that some research grant expired, the original maintainers are no longer paid, and hackers used the opportunity to impersonate the team and direct users to a new pypi package - because of all things that you could hack or take over, pypi is difficult.

We need to exclude this specific possibility, since there seem to be no good reasons why you would rename a package that has this high amounts of adoption.

That the webpage got hijacked is not a positive signal here. We need to rule out that the package got hijacked as well.

[amotl]

Sure, better safe than sorry. I tend to think it's all good, because Luís Portela Afonso (@portellaa) has been committing to the code base since 2022, and still does.

Maybe @portellaa knows more, as he implemented the rename with Data-Centric-AI-Community/fg-data-profiling@628d400 the other day?

Based on those indications, I think a group of people took over maintenance under a different umbrella, similar like some of us are doing it across the board. Let me know what you think about it, and how we could increase community trust in the new package again, when applicable?

[fkiraly]

Based on those indications, I think a group of people took over maintenance under a different umbrella,

That answer does not satisfy me, really. A package rename is by itself suspicious, and we should find out what happened. Best case is some kind of rebrand enforced by KPMG.

The "took over maintenance under a different umbrella" explanation does not make sense under your explanation:

• pypi account owner is the same
• key people formerly involved are also involved with the fork
• renaming a package hurts your user base, so experienced maintainers would want to avoid this (compare: pypi accounts are same owners)

[fkiraly]

Another possibility: KPMG took over ydata, and they kicked out the open source package?

Either way, I think it is key to look at de-facto governance and legal status (e.g., ownership)

[fkiraly]

I will try to get in touch with @portellaa to get more details

[amotl]

Another possibility: KPMG took over ydata, and they kicked out the open source package?

Right, I think it's in between: The GitHub project/repository did not change but was transferred. The name change had to take place because KPMG now owns the YData brand (and packages).

Either way, I think it is key to look at de-facto governance and legal status (e.g., ownership). I will try to get in touch with @portellaa to get more details.

Thanks. I guess he will answer and confirm roughly the same details we've explored here already.

[portellaa]

hey guys,

it's the same package, yes.

as @amotl stated, yes ydata was acquired by KPMG.
we are still the same working in the projects, but now we are pushing our comercial solutions through KPMG and so on, but the community is still the same.

we were trying to make it only data-profiling, as the as same as data-synthetic and data-quality, but some of the name was already taken so we decided to go through fg-data- ...
(and its not fabiana and gonçalo 🤣 but i don't remember what driven that 🤣)

but no worries, yes its all legit we are the same behind this, just under a bigger company now.

i hope this clarifies everything.

cheers 🍻

[fkiraly]

@portellaa, thanks for the clarification. This still does not explain the name change though, why did you change the name?

@amotl, @siddharth7113, I would strongly suggest we stay away from commercially controlled open source. Inevitably, there is a license change or attempted lock-in. Certainly with KPMG who only have proprietary SaaS and closed licenses for their products.

Given that ydata-profiling was used only in two locations, and both times the ProfileReport, which is very simple to replace.

In previous versions of pycaret, it also seems that ydata-profiling was never explicitly referenced in the documentation - which would have been essential in the documentation of at least the profile_kwargs - this is at least odd.

I would even turn the argument into a callback of signature so it can be used as

self.report = profile(self.data)  # or with profile_kwargs
# later:
self.report.to_file(profile_path)  # writes an html file

This would allow ydata-profiler profiler, but also other callbacks that the user may be interested in.

The ydata-profiler profile can be the default, and we could deprecate it with a message that points people to fg-profiler, as well as to a new default that no longer relies on soft dependencies. fg-profiler can be mentioned in the docstring.

[amotl]

@fkiraly: As far as I can see, a replacement is straight-forward as suggested with this patch. If you want to go further, please submit a different proposal, or track it using a dedicated issue. If this patch is not desirable, let's close it and wait for a different one?

Can you outline why a more sophisticated change is needed? For me, it looks like fg-data-profiling is the normal way forward, as regularly announced in their README. The MIT license also didn't change in any way, @portellaa said everything is all right, so I don't see a reason not to trust the same authors like before. If anything actually changes which you are not comfortable with, the code can be changed at your disposal. Until then, I'd consider any such changes as premature optimizations?

[siddharth7113]

@portellaa, thanks for the clarification. This still does not explain the name change though, why did you change the name?

@amotl, @siddharth7113, I would strongly suggest we stay away from commercially controlled open source. Inevitably, there is a license change or attempted lock-in. Certainly with KPMG who only have proprietary SaaS and closed licenses for their products.

Given that ydata-profiling was used only in two locations, and both times the ProfileReport, which is very simple to replace.

In previous versions of pycaret, it also seems that ydata-profiling was never explicitly referenced in the documentation - which would have been essential in the documentation of at least the profile_kwargs - this is at least odd.

I would even turn the argument into a callback of signature so it can be used as

self.report = profile(self.data)  # or with profile_kwargs
# later:
self.report.to_file(profile_path)  # writes an html file

This would allow ydata-profiler profiler, but also other callbacks that the user may be interested in.

The ydata-profiler profile can be the default, and we could deprecate it with a message that points people to fg-profiler, as well as to a new default that no longer relies on soft dependencies. fg-profiler can be mentioned in the docstring.

@fkiraly: As far as I can see, a replacement is straight-forward as suggested with this patch. If you want to go further, please submit a different proposal, or track it using a dedicated issue. If this patch is not desirable, let's close it and wait for a different one?

Can you outline why a more sophisticated change is needed? For me, it looks like fg-data-profiling is the normal way forward, as regularly announced in their README. The MIT license also didn't change in any way, @portellaa said everything is all right, so I don't see a reason not to trust the same authors like before. If anything actually changes which you are not comfortable with, the code can be changed at your disposal. Until then, I'd consider any such changes as premature optimizations?

My comments here are limited to the technical aspects of the change; I’m refraining from commenting on the broader governance of the upstream project until I’ve had a chance to review it properly.

Independently of that discussion, I think we should aim to eventually remove ydata-profiling, as previously highlighted here. The project does not appear to be receiving frequent technical updates; the last technical fix I could find is from last year -
Data-Centric-AI-Community/fg-data-profiling@45d76ea

I also think @fkiraly's suggestion would be a technical improvement. However, I agree making it a separate issue/PR is a better idea, since similar changes could benefit other parts of the repository as well.

For an immediate fix, I would be fine with replacing the dependency as proposed here, while putting an upper bound on the dependency version. That would allow us to stay within the currently known licensing terms if those terms change in a future release.

[portellaa]

@fkiraly everything that has ydata in the name was acquired by KPMG, even with us moved to KPMG and still working in the same concept or same products, the public part of the company, the datascience community and what this projects bring and give, were not sold or part of the deal we did with KPMG.

We did get in touch with pypi because we wanted to keep simple and have just data-* but there was one of the names that was taken, so we went with this.

The projects that were renamed:

• https://pypi.org/project/fg-data-synthetic/
• https://pypi.org/project/fg-data-quality/
• https://pypi.org/project/fg-data-profiling/

But the maintainer is still ydata and everything is the same, instead of from ydata_profiling import ProfileReport it's just from data_profiling import ProfileReport 😂

I hope this helps clarifying the question, there is nothing shady, trust us.

Cheers 🍻

[amotl]

The name was changed because everything that has ydata in the name was acquired by KPMG.

Thanks for confirming, @portellaa.

Independently of that discussion, I think we should aim to eventually remove ydata-profiling, as previously highlighted #56 (comment). I also think @fkiraly's suggestion would be a technical improvement. However, I agree making it a separate issue/PR is a better idea, since similar changes could benefit other parts of the repository as well.

Excellent, thanks!

For an immediate fix, I would be fine with replacing the dependency as proposed here, while putting an upper bound on the dependency version. That would allow us to stay within the currently known licensing terms if those terms change in a future release.

I've just added an upper bound on the major version, thanks!

[amotl]

Hi again. @gmartinsribeiro also responded to my report about the domain hijacking:

The domain was taken by a third party during the transition from YData to KPMG, because we did not renew it.
We will take down the pointer to the website from GitHub, because now it belongs to someone else. Thank you for sharing this.

Thank you!