splat VS pylance-release

This is a simple Service Locator for Dart and Flutter projects with some additional goodies highly inspired by Splat. It can be used instead of InheritedWidget or Provider to access objects e.g. from your UI.

I read through the PR discussion in question as part of reading Rob Mensching's post before I came across this discussion, and thought that she'd overstepped. However, after watching Tim Corey go through the same discussion, I realise that not only did she overstep, she appeared to actively (and publicly) fight with the current maintainer. Her actions appear (to me) to be completely arrogant, selfish, uncaring, and frankly dangerous to the project.

Head of .NET Foundation creates and merges a PR for a change they made to a project where they hadn't been active for several years. When confronted by current maintainers, their response was at the very least, hostile and poorly thought out.

Many projects joined the .NET Foundation after it was created. It didn't really do anything, but it wasn't harming anyone either.

The .NET Foundation asked for owner access on a repository (for their CLA bot). The author declined and a workaround was organized.

Years later the .NET Foundation asked for owner access on a repository (to allow them enforce Code of Conduct across all repositories. The author declined.

The CLA bot stopped working. The author was told it would work if he gave it owner access. The author was annoyed because they previously had a workaround. They gave in and gave @dnfadmin owner access.

The author woke up and realized that the project had now been silently moved to GitHub Enterprise. The author states that projects in GitHub Enterprise can be entirely controlled by the owner of the account (the .NET Foundation). This transfer happened silently.

Independently, this happened to another project (who had coincidentally had an issue with a Microsoft employee and former contributor force a pull-request into their project: https://github.com/reactiveui/splat/pull/778).

People are upset because of how tone-deaf all of this is. They would like the .NET Foundation to stop trying to gain complete control over the member projects. They would like Microsoft employees to not force pull requests into their projects.

> I am not versed in all the details here

You should probably read the conversation in the PR: https://github.com/reactiveui/splat/pull/778

> there is a dire need for professional communications training among these programmers.

Maybe, but probably not why you think.

Once you've read the PR's conversation you'll see this isn't about someone just merging a PR which wasn't approved. This about someone submitting a PR, a maintainer asking for discussion before merging it, ignoring the maintainer and just merge the PR, the maintainer asking why it wasn't discussed and then making a snide remark to the maintainer.

So I agree that the "Sorry for merging a PR" isn't going to cut it here. The merging of the PR was the least of the problem. It's a hollow corporate-style apology where someone is allowed to be called out for. It's like saying: "Sorry I hurt your toe" after you pushed someone of a cliff.

Library inspired by Splat from the React world again. Library is not so popular like previous and maintenance is also a little lower.

One of the things that comes to mind here is the fact that the default Python extension for VS Code is, perhaps surprisingly to many, not open source. https://github.com/microsoft/pylance-release

While it's possible to fork VS Code, it is not possible to fork VS Code and provide a seamless onramp towards a Python editing experience that is fully open source, because users are used to the nuances of the closed-source Pylance experience in VS Code proper. You could use the minified/compiled Pylance plugin in your fork, but you'd have no way to expand its capabilities to new hooks your fork provides. Microsoft's development process would always be able to move faster than a fork, because it could coordinate VS Code internal API development with its internal Pylance team, and could become incompatible with forks at any time.

It's worth re-reading the quote from J Allard in https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... with this modern example in mind.

(Also worth mentioning https://github.com/detachhead/basedpyright?tab=readme-ov-fil... which is a heroic effort to derisk this, but it's an uphill battle for sure!)

Anyone know how can we fix this issue if we build the vscode locally

Do any of these issue tickets explain the behaviour you're seeing? https://github.com/microsoft/pylance-release/issues/4341, https://github.com/microsoft/pylance-release/issues/4071

Maybe they "are the same thing" in terms of behavior (I don't know), but "A uses B" doesn't mean that "A is B".

One important difference in this case is that while "Pylance leverages Microsoft's open-source static type checking tool, Pyright" [1], Pylance itself is not open source. In fact, the license [2] restricts you to "use [...] the software only with [...] Microsoft products and services", which means that you are not allowed to use it with a non-Microsoft open source fork of VS Code, for example.

The license terms also say that by accepting the license, you agree that "The software may collect information about you and your use of the software, and send that to Microsoft" and that "You may opt-out of many of these scenarios, but not all".

[1] https://github.com/microsoft/pylance-release

[2] https://marketplace.visualstudio.com/items/ms-python.vscode-...

There's this one: https://github.com/microsoft/pylance-release/issues/4174 (rules don't apply properly, and ovverrides don't work even after being set, this is especially for the more generic ones like )

The example is not .NET in general, but that specific event when Microsoft reneged on open development tooling[1]. For some people, that was the moment they stopped trusting "new Microsoft" to keep their word (though for me, it was when the Python language server was replaced with a DRM-locked, LSP-noncompliant one[2] a bit before that; unlike .NET hot reload, they didn't backtrack there). I can think the company makes great open .NET tools and at the same time not trust them to close it down on a whim.

Does anyone know where the open xlang reimplementation of MIDL went[3], by the way? (Unlike 1990s MIDL, you can't reimplement this one from the language grammar in the docs, because there is no language grammar in the docs.)

[1] https://dusted.codes/can-we-trust-microsoft-with-open-source and links there

[2] https://github.com/microsoft/pylance-release/issues

[3] https://github.com/microsoft/xlang/pull/529