Severe namespace conflict with OpenTK in Xamarin.Android and Xamarin.iOS

[varon]

OpenTK has improved significantly since this fork was made many, many years ago.

If this fork was no longer automatically included on those platforms, we would no longer have severe namespace conflicts, allowing users to make use of the newer versions of OpenTK which we provide.

See:
https://bugzilla.xamarin.com/show_bug.cgi?id=18575
https://bugzilla.xamarin.com/show_bug.cgi?id=52168
https://bugzilla.xamarin.com/show_bug.cgi?id=52169
https://bugzilla.xamarin.com/show_bug.cgi?id=56017

OpenTK Parent issue:
opentk/opentk#810

We would really like to work together with you guys in allowing Xamarin iOS and Xamarin Android users to use the much improved version of the library.

A bunch of mentions from the above issues:
@Nihlus @dalexsoto @tzachshabtay @cobey @jonpryor @topgenorth @mkrueger @DhirenSarup @radekdoulik

[radekdoulik]

We cannot remove our OpenTK assemblies as it would break existing projects of our customers. Also note that mono/OpenTK was improved over the years as well.

It would make more sense to try to solve the issues which might make using opentk/OpenTK in projects of Xamarin users complicated.

I am aware about Xamarin.iOS containing parts of the API. I think the solution for that was proposed by @dalexsoto here https://bugzilla.xamarin.com/show_bug.cgi?id=52169#c3.

On Android I think it should be possible to use custom OpenTK version in projects built with Xamarin.Android.

[varon]

Thanks for getting back to us so fast. It's good to get this discussion started.

We cannot remove our OpenTK assemblies as it would break existing projects of our customers.

We're aware that there are breaking changes between the versions. We're asking to give users the choice like they do with any other package.

Also note that mono/OpenTK was improved over the years as well.

There's literally four commits since 2015. Any changes you've made we could easily integrate back into the main project from your fork. It's not going to take more than a few hours to re-do these changes.

I think the solution for that was proposed by @dalexsoto here https://bugzilla.xamarin.com/show_bug.cgi?id=52169#c3.

This is in no way a solution. The types used by Xamarin are out of date and do not include the fixes, updates or enhancements we've made. This would also completely prevent us from ever being able to improve them in the future on these platforms. See opentk/opentk#755

[radekdoulik]

We're aware that there are breaking changes between the versions. We're asking to give users the choice like they do with any other package.

It is not about the changes between the 2 OpenTK assemblies. It is about users not being able to build their project after an hypothetical update. (when the update would drop the assembly which was part of the kit before)

There's literally four commits since 2015. Any changes you've made we could easily integrate back into the main project from your fork. It's not going to take more than a few hours to re-do these changes.

The fork happened in 2011 so these are not just 4 changes.

This is in no way a solution. The types used by Xamarin are out of date and do not include the fixes, updates or enhancements we've made.

I am not sure we talk about the same idea here. @dalexsoto would know better, but if I remember correctly, the Xamarin.iOS uses small subset of the API. So to make it possible to use custom OpenTK with it, the custom OpenTK would need to either use the old API from Xamarin.iOS or rename that part of API to avoid conflicts.

[Perksey]

The biggest issue here is that Xamarin users our unable to consume our (official) version of OpenTK, due to the namespace, so the most ideal solution, if you desperately need your outdated fork, is that you change the namespace of your fork. This will enable the official version to be installed on Xamarin platforms, but those who want to continue using the ancient version just need change their namespace.

[varon]

It is not about the changes between the 2 OpenTK assemblies. It is about users not being able to build their project after an hypothetical update. (when the update would drop the assembly which was part of the kit before)

It's pretty commonly known that things break when you update. Certainly it wouldn't be out of the ordinary given my experience in using Xamarin in production. Especially if it's an easy fix like we're proposing.

To let them know about when/why, it wouldn't require much more than a blog post from you guys on the update explaining which namespaces they need to change to get the old functionality.

The fork happened in 2011 so these are not just 4 changes.

The point I'm making is that it's far behind the main project. As before, we're happy to integrate any number of improvements that you may have made.

the Xamarin.iOS uses small subset of the API. So to make it possible to use custom OpenTK with it, the custom OpenTK would need to either use the old API from Xamarin.iOS or rename that part of API to avoid conflicts.

You must see the irony in asking the main project which you forked from to change namespaces.
We're trying to bring updates to your platform and let your users actually update their software.

What we propose is pretty simple:

If Xamarin cannot function without parts of OpenTK, then please can you change those namespaces to allow people to use an updated version of the library without conflicts.

[spouliot]

We understand the issue(s) and the historical facts that led to the current, suboptimal situation. Sadly there's no time machine to go back and fix this in a painless way.

The suggested solution is a major breaking change affecting all Xamarin customers. It means it would break both source code and existing binaries (some of which customers might not have ways to update, e.g. commercial 3rd parties).

When (or if) we face a situation that force us to do a breaking change in the future then we'll consider this request (it's what we call XAMCORE_4_0 internally for iOS and macOS).

Until then our policy remains to avoid breaking changes that requires all of customers to update all their project's sources and binaries. Our move to unified/64bits proved, in a smaller scale then, how painful this can be for everyone in the eco-system.

[Perksey]

I respect that, however if your customers use OpenTK we should be responsible for their usage of it, and our aim is to get all users able to consume the latest and greatest update; a goal which is forking hard to achieve when this fork blocks any Xamarin users of the official build from updating.

For the sake of the project which you are referencing, we ask that you do something to help us out (like the solution we’ve already proposed), otherwise we may not be able to target the Xamarin platforms, something we really do not want to resort to.

[winterhell]

For argument's sake, do you have a number of users actually using Xamarin.OpenTK?
I really tried googling that up and couldn't find any game whatsoever that does so.
If there isnt actually anyone using it then there is no argument about breaking compatibility with non-existing users.

[varon]

@spouliot, let's think about this for a bit here... Probably less than 0.01% of your users have a single using OpenTK statement in their code. for the VAST majority of your userbase, it's not a breaking change. With a properly engineered solution, here are our outcomes:

For people actually using your OpenTK fork

You would be doing them a great big favor by allowing them to escape your unsupported and ancient fork of the project.

For everyone else

If they're not actually opening the OpenTK namespace and you change it along with your internal references, then there's absolutely no reason the internal change can't be done transparently.

---

With your proposed non-solution, your users get stuck with an ancient and shitty fork of the software, while you refuse help from people actively trying to improve your product.

You have an entire community of passionate developers that will go to extended lengths to get this done. Work with us and let us help you improve your platform. Your current decision is defensive, short-sighted and lazy. This problem affects both of us. Stop giving us the middle finger and work with us.

[migueldeicaza]

There are a couple of elements here. First, some data types were imported directly into Xamarin libraries (data types like vectors, matrices and a handful of others) and a fork of OpenTK was used.

At the time of this work, the OpenTK code was not being maintained.

Later, OpenTK came back to life, but it came to life with breaking changes. Ideally, this should not happen, but when it does, the library with the different API needs to have a mechanism to prevent breaking existing code. There are several ways of achieving this, some people version their assemblies, other folks use new namespace, or new type names.

We are not going to break customer code for the reasons that Sebastien outlined above.

Given that constraint, I think that the solution to the OpenTK issue on mobile is to ship the package with a different assembly name. Users that want to upgrade and use a new API can do that at their own pace.

[varon]

Fuck you too.

[Nihlus]

We are versioning our assembly. Xamarin is artificially locking users to their bundled source and preventing other methods of using upstream. And even if we went with a differently named assembly, the namespace clashes are still there.

You're killing any hope of amicable collaboration between OpenTK and Xamarin. If you're not going to give us even an inch, what makes it worth it for us to bend over backwards to make this work?

[Perksey]

Why are you blaming us exactly? Xamarin are the ones who've taken our project and used it in a way that blocks of a whole range of targets, and now they're also the ones who are attempting to inconvenience the original project? I get that this is awkward for everyone involved, but making a change this vast invalidates all of the tutorials that we are writing for 4.0 and, considering one of our goals are unifying the platforms, this is no way helping us!

[tzachshabtay]

I don't think getting personal or playing blame games is helpful here, it's not productive and it doesn't really matter who's to blame for getting to this situation.

What's important, I think, is what will be better for the users: mono/opentk looks to be completely neglected. Apart from the 5 commits since 2015 that was already mentioned, I can also add zero responses to any of the opened issues here (except from this one).
I suspect most of xamarin users (and I am one of them) are effectively using (or trying to use) the official opentk which is actively maintained and developed.
Therefore I doubt there are a lot of xamarin users which will be affected by these breaking changes, but there are a lot of users who will gain from this move.

Also, this will also help xamarin in the long-term, as you'll need one less library to maintain.

[ghost]

So how are we going to improve this then?

[ticotaco72]

Hello, I'm contributing to multi-platform project creating Android support. Now I don't see any alternative for me to force whole project to use OpenTK with changed namespace. It's not big effort but it's very confusing. So why can't you change this one namespace instead of all of your users do this themselves. No-one who knows what he's doing , uses your 1.0 OpenTK. Your thinking is so stupid.

Microsoft as company "changes" its view to be "open-source friendly". But this example shows the opposite. It's only one click on find & replace and maybe write some info about change on xamarin blog. Someone from top of Microsoft should talk with person that is too lazy to do that small effort. And maybe that person should be kicked off from the company.

[peppy]

@ticotaco72 it's not that simple, as it breaks compatibility with all projects and libraries built on top of xamarin. I don't believe this is a result of laziness.

The opentk project has already agreed (before this very issue was posted, weirdly enough) to change the namespace so this should be a non-issue once completed.

[glopesdev]

I have been using OpenTK on desktop platforms for nearly 10 years now, and the project itself has more than 14+ years, having been started around 2006. It is a well-known .NET open-source project, made out of love by a single developer, and rescued from the brink of destruction several times in the past.

I myself was coming back now to updating all my projects to the latest OpenTK in preparation for a major overhaul for .NET Core and .NET 5.0 when I was confronted by this issue.

It is very disappointing to have an open-source project with such a history be pushed aside in the interests of commercial support. As @migueldeicaza said, when there are breaking changes, mechanisms should be put in place to redirect older code to the proper place.

While I completely agree with this position, in this case Xamarin.Mac is the absolute mediator, AND the one with the bigger budget, AND the one who appropriated OpenTK in the first place, so it is only right that it should be the one to budge, and NOT OpenTK.

I know Xamarin itself is not alien to these values, and it is very sad to see what happened in this thread. This is not just a namespace change, it is the shunning of the identity of a project that shaped the open-source .NET community to the extent that you yourselves have found it fit to use it.

[varon]

@glopesdev - Thanks for your support.
We changed the namespaces and there's an enormous amount of progress - 4.0 is almost there!
If you're up for it, there's a very active community on Discord. We'd love to have you join us!