Add back **kwargs to pipelines for custom development

Is your feature request related to a problem? Please describe. Removing **kwargs has no clear use other than making development and customization of diffusers more a chore.

Being able to pass anything to a pipe, and utilize it within diffusers API was nothing but beneficial, and I don’t see why it was removed.

Describe the solution you’d like Add **kwargs back to constructors and methods

Describe alternatives you’ve considered Editing every pipe and file of diffusers relevant.

Additional context Please start planning changes, announce them to the community, so they can be appropriately handled by users. It is negligent to make end-breaking changes without providing documentation for the coming changes.

Start PR-ing your own repo for changes for community feedback, as many changes are becoming controversial, and lacking foresight.

[patrickvonplaten]

@WASasquatch, please note that we won’t much longer tolerate such statements in the diffusers library from you and if it continues will block you from this GitHub repo.

We don’t want the diffusers github repository be a place where strong language and negativity is supported and tolerated. We take feedback seriously but we need more than negative complaints to make that happen. By consonantly letting you post extremely negative statements that are often unrelated to the topic of the issue, we set an bad example for our community members and don’t make diffusers an inviting repository for open-source contributors.

To be clear, as maintainers, we want to foster:

• Positive communication (“Good idea, but this could be done better because a, b, c. Here is an example of how would image a potential solution …”)
• Constructive feedback that is related to the issue (“By adding back **kwargs to pipelines, I see a problem that you make it more difficult for repositories that depend on diffusers to freely customize the pipeline to their needs”)
• Give everybody the feeling to be invited to discuss issues, PRs and to open PRs. Negativity and harsh language make this repository less inviting for people.

Here are some examples where you have - in our opinion - disrespected one or more of the above values: 1.

Don’t assume we’re so stupid, again, that we can’t figure stuff like this out

link here => is not positive language 2.

is ridiculous

link here => is neither constructive feedback nor positive 3.

Humble yourselves to critique and criticism.

link here => is not inviting, positive or constructive langugae 4.

smiling_face_with_tearCryingFace is a wreck lately.

link here => is insulting and not constructive 5.

certainly not users jobs to maintain diffusers

link here => does not give people the feeling to be invited - we want people to take ownership of the code they add. That’s how open-source should work 6.

… just locking everything down to do a paid version?

link to edited message here => is insulting to us and not constructive 7.

And from Hugging Face Diffusers, seemingly assuming most their users are too lazy or inept to read documentation is pensive face not hugs

link here => is insulting and very negative

We won’t tolerate such statements any longer, so please make an effort to be more positive. Note that diffusers is an open-source project, that you don’t have to use. It’s the right of the maintainers to define the scope and atmosphere of the diffusers project. If you don’t like it - which seems to be the case from your comments - please either give us constructive feedback according to the values defined above or simply use another open-source software.

That being said, I can understand the frustration of a fast changing API, constant design choices/changes that you don’t agree with and that might break your downstream code, but please make an effort to keep feedback technical & constructive and in a motivating, positive tone. But here again, if the API just doesn’t work out for your use case, please fork this repo or use a different library.

Also, personally, I might also have been negative to you on GitHub, so please do point this out and I’ll try to change it.

Finally, I’ve also just send you an email (the one on your GitHub account) in an attempt to speak face-to-face to ease the tension here a bit.

[patrickvonplaten]

“Our dilemma is that we hate change and love it at the same time; what we really want is for things to remain the same but get better.” - Sydney J. Harris

Ha. 😉

I just don’t see the point. It’s like checking if classes came from diffusers (custom safety checker pipelines or w/e). Are they just locking everything down to do a paid version? So development of forks or active versions via patching is a pain? “Welp, I might as well pay for paid support” (nodding at the HF survey).

I don’t know what the statement

“… just locking everything down to do a paid version?”

has to do with the above issue. It’s extremely disappointing to read such statements as a maintainer and I hope that you could discuss such matters on other mediums such as discord, twitter, etc…, but not spam core-maintainers with such statements. We have to read every issue that is put up and would love to not loose time on completely irrelevant and negative statements such as the above.

At Hugging Face, we have been putting in lots of effort & energy to build state-of-the-art & free open-source libraries (all MIT licensed) to accelerate the adoption of ML technologies for everybody. Nothing has ever been changed to a paid version.

@WASasquatch, I sincerely hope that you could stop commenting with messages like those when opening issues. No one is forcing you to use diffusers; if you don’t like it, feel free to use an alternative or fork the repo. If you believe, we are doing everything in bad intent here, feel free to express your opinion elsewhere, but please keep the issues as technical issues of the library. Thank you!