Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotnet 3.1 is EOL #202572

Closed
7 tasks done
mdarocha opened this issue Nov 23, 2022 · 28 comments · Fixed by #222422
Closed
7 tasks done

dotnet 3.1 is EOL #202572

mdarocha opened this issue Nov 23, 2022 · 28 comments · Fixed by #222422
Assignees

Comments

@mdarocha
Copy link
Contributor

mdarocha commented Nov 23, 2022

Issue description

Since December 13, .NET 3.1 is unsupported, as per https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

We should work on updating packages that make use of it, and deprecating this dotnet version

Steps to reproduce

See https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core

Replacing packages using dotnet-sdk_3

cc @IvarWithoutBones @GGG-KILLER

@mdarocha
Copy link
Contributor Author

Also we should probably update the documentation examples to refer to newer .NET versions.

@GGG-KILLER
Copy link
Contributor

I don't know if we should address this at the same time, but .NET 5.0 has already hit EOL and it has no warnings at all:

dotnet_5_0 = import ./versions/5.0.nix (buildAttrs // { inherit icu; });

@mdarocha
Copy link
Contributor Author

I don't know if we should address this at the same time, but .NET 5.0 has already hit EOL and it has no warnings at all:

dotnet_5_0 = import ./versions/5.0.nix (buildAttrs // { inherit icu; });

See #173115 :)

@GGG-KILLER
Copy link
Contributor

GGG-KILLER commented Nov 23, 2022

Have checked the listed packages that depend on .NET Core 3.1:

  • wasabibackend: if we update it, we'll be able to move it to .NET 6.0
  • alttpr-opentracker: if we update it, we'll be able to move it to .NET 6.0
  • baget: still on .NET Core 3.1 on source (will block full removal, we'll probably need to mark .NET Core 3.1 with a warning as deprecated or get rid of this package)
  • azure-functions-core-tools: if we update it, we'll be able to move it to .NET 6.0 (partially in progress at azure-functions-core-tools: 3.0.3785 -> 4.0.4736 #181126, however still using .NET Core 3.1 to run)
  • inklecate: if we update it, we'll be able to move it to .NET 6.0
  • python-language-server: repo has been archived, should be removed

@mdarocha
Copy link
Contributor Author

What's the alternative to python-language-server then? I use it personally, for example.

And as for baget: is there any work done on the upstream to migrate it? Or should we remove the package as the upstream is not maintained?

I remember @IvarWithoutBones attempted to add a warning for .NET 5 in #175354 but it could not be merged, since throwing warnings caused ofborg to fail.

@GGG-KILLER
Copy link
Contributor

GGG-KILLER commented Nov 23, 2022

What's the alternative to python-language-server then? I use it personally, for example.

And as for baget: is there any work done on the upstream to migrate it? Or should we remove the package as the upstream is not maintained?

I remember @IvarWithoutBones attempted to add a warning for .NET 5 in #175354 but it could not be merged, since throwing warnings caused ofborg to fail.

About python-language-server I don't see any alternatives, but I see it as a risk to keep any packages that still depend on .NET 3.1 as there might be security vulnerabilities in them.

As for baget, there's a PR (loic-sharma/BaGet#717) open for over 10 months with no signs of being merged. It seems the maintainer hasn't been very active as of recently so I don't think we should bet on it being merged soon.

@mdarocha
Copy link
Contributor Author

Note that wasabibackend and wasabiwallet seem to be different packages

@JamieMagee
Copy link
Member

The replacement for python-language-server is python-lsp-server.

There are currently 2 packages that depend on python-langauge-server in nixpkgs:

Both of those packages currently have upstream PRs to migrate from python-language-server to python-lsp-server:

Once those PRs are merged, and they are updated in nixpkgs, we can remove python-language-server.

@JamieMagee
Copy link
Member

I attempted to updated allptr-opentracker to 1.8.5, which targets .NET 6.0, but there was an issue with the build. I opened an issue upstream: trippsc2/OpenTracker#86

@JamieMagee
Copy link
Member

The upstream maintainer for baget appears to be unresponsive right now. I think we need to wait and see if a supported fork appears: loic-sharma/BaGet#717 (comment)

@GGG-KILLER
Copy link
Contributor

GGG-KILLER commented Jan 5, 2023

The replacement for python-language-server is python-lsp-server.

There are currently 2 packages that depend on python-langauge-server in nixpkgs:

Both of those packages currently have upstream PRs to migrate from python-language-server to python-lsp-server:

Once those PRs are merged, and they are updated in nixpkgs, we can remove python-language-server.

Looking into pyls-mypy and pyls-black, both seem to be unmaintained (former having the most recent commit in 2020 and latter in 2021).

Don't know if we should put much hope in having them move over to the maintained LSP.

UPDATE: Both seem to depend on palantir's language server which is Python-only, not microsoft's.

@GGG-KILLER
Copy link
Contributor

I attempted to updated allptr-opentracker to 1.8.5, which targets .NET 6.0, but there was an issue with the build. I opened an issue upstream: trippsc2/OpenTracker#86

This is something we can solve temporarily by using dotnet sln remove in prePatch or postPatch, isn't it?

@JamieMagee
Copy link
Member

This is something we can solve temporarily by using dotnet sln remove in prePatch or postPatch, isn't it?

Yeah. I was hoping for an upstream fix, but we can patch in the meantime.

@JamieMagee
Copy link
Member

Looking into pyls-mypy and pyls-black, both seem to be unmaintained (former having the most recent commit in 2020 and latter in 2021).

Don't know if we should put much hope in having them move over to the maintained LSP.

UPDATE: Both seem to depend on palantir's language server which is Python-only, not microsoft's.

Lets replace them with their maintained forks

Then remove python-language-server as it's unmaintained, and won't have any dependencies on it anymore.

@mdarocha mdarocha changed the title dotnet 3.1 will soon be EOL dotnet 3.1 isEOL Jan 7, 2023
@mdarocha mdarocha changed the title dotnet 3.1 isEOL dotnet 3.1 is EOL Jan 7, 2023
@JamieMagee
Copy link
Member

JamieMagee commented Jan 7, 2023

Removing python-language-server

@GGG-KILLER
Copy link
Contributor

Update on this, it seems like the VSCode live share extension also depends on 3.1:

makeWrapper $PWD/dotnet_modules/vsls-agent{-wrapped,} \
--prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath libs}" \
--set LD_PRELOAD $PWD/dotnet_modules/noop-syslog.so \
--set DOTNET_ROOT ${dotnet-sdk_3}

@mdarocha
Copy link
Contributor Author

Update on this, it seems like the VSCode live share extension also depends on 3.1:

makeWrapper $PWD/dotnet_modules/vsls-agent{-wrapped,} \
--prefix LD_LIBRARY_PATH : "${lib.makeLibraryPath libs}" \
--set LD_PRELOAD $PWD/dotnet_modules/noop-syslog.so \
--set DOTNET_ROOT ${dotnet-sdk_3}

I updated the todo list. Is there an update or a replacement of that package that bumps the used dotnet version?

@GGG-KILLER
Copy link
Contributor

I updated the todo list. Is there an update or a replacement of that package that bumps the used dotnet version?

I have downloaded the latest version of the extension and haven't found the binary being patched, I'm unsure if it is now being downloaded at runtime or if they replaced it entirely with js.

@GGG-KILLER
Copy link
Contributor

GGG-KILLER commented Feb 17, 2023

After a quick check on the latest version of the liveshare extension, it seems like it no longer uses a .NET binary for the live share functionality and everything got reimplemented in javascript.

If someone else confirms this I think it's safe to just upgrade it and remove the .NET patching from it.

@jraygauthier and/or @deviant can you confirm this as package maintainers?

EDIT: No need for further confirmation, I've found this comment confirming it indeed got removed: microsoft/live-share#1272 (comment)

@JamieMagee
Copy link
Member

That means the only remaining package to update is BaGet. What should we do? Apply patches to the existing package or migrate to the maintained fork?

@mdarocha
Copy link
Contributor Author

That means the only remaining package to update is BaGet. What should we do? Apply patches to the existing package or migrate to the maintained fork?

Migrating to the fork should be fine?

@GGG-KILLER
Copy link
Contributor

GGG-KILLER commented Feb 22, 2023

That means the only remaining package to update is BaGet. What should we do? Apply patches to the existing package or migrate to the maintained fork?

I think we could migrate to the fork. The only thing that worries me a bit are the recent commit messages but I don't know if I'm just being pedantic.

@mdarocha
Copy link
Contributor Author

Unfortunately I had problems bulding the fork, I posted a comment in the PR about the issues.

@GGG-KILLER
Copy link
Contributor

GGG-KILLER commented Mar 12, 2023

I don't know if this is the place to discuss this, but should we really replace the official package by a fork that was only made for a PR and has no issues enabled (therefore no support)?
Even more so when the official project that it's getting PR'd into seems to be dead (for the lack of a better word)?

I think a better alternative would be to remove the package while a proper fork is not found

@mdarocha
Copy link
Contributor Author

That's probably the better course of action

@mdarocha
Copy link
Contributor Author

I made a PR for removal of baget, after it we can remove .NET 3.1 completely from nixpkgs :)

@mdarocha
Copy link
Contributor Author

And its done :)

@JamieMagee
Copy link
Member

Thanks! See you all for .NET 7 EOL 😂

@JamieMagee JamieMagee mentioned this issue Jul 11, 2024
17 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants