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-sdk : init at 2.0.3 #30750

Merged
merged 1 commit into from Oct 24, 2017
Merged

dotnet-sdk : init at 2.0.3 #30750

merged 1 commit into from Oct 24, 2017

Conversation

kuznero
Copy link
Member

@kuznero kuznero commented Oct 24, 2017

Motivation for this change

Introduce dotnet-sdk package (dotnet client utility).

Things done

Wrapped pre-built linux binaries.

  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@kuznero
Copy link
Member Author

kuznero commented Oct 24, 2017

@copumpkin, @Mic92, @obadz please review.


let
rpath = stdenv.lib.makeLibraryPath [ stdenv.cc.cc libunwind libuuid icu openssl zlib curl ];
version = "2.0.3";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

version should be an attribute inside mkDerivation.

in
stdenv.mkDerivation rec {
name = "dotnet-sdk-${version}";
src = fetchTarball "https://dotnetcli.azureedge.net/dotnet/Sdk/2.0.3-servicing-007037/dotnet-sdk-2.0.3-servicing-007037-linux-x64.tar.gz";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use some fixed output abstraction, fetchurl is probably most appropriate.

@@ -0,0 +1,46 @@
{ stdenv
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

commit message should follow the style "package: init at version"

@kuznero
Copy link
Member Author

kuznero commented Oct 24, 2017

@adisbladis thanks for review, addressed

'';

meta = with stdenv.lib; {
homepage = http://dotnet.github.io/core/;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

url returns 404.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, thanks

@kuznero kuznero changed the title Introduce dotnet-sdk package dotnet-sdk : init at 2.0.3 Oct 24, 2017
@copumpkin
Copy link
Member

Does anything refer to this file?

@kuznero
Copy link
Member Author

kuznero commented Oct 24, 2017

@copumpkin not yet. Would you suggest adding it to top level packages?

@copumpkin
Copy link
Member

Yeah, or if not, explain somewhere how to use it.

@kuznero
Copy link
Member Author

kuznero commented Oct 24, 2017

@copumpkin done

@copumpkin
Copy link
Member

@GrahamcOfBorg dotnet-sdk

Copy link

@GrahamcOfBorg GrahamcOfBorg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dotnet-sdk version: 2.0.3-servicing-007037
installing
post-installation fixup
stripping (with flags -S) in /nix/store/5jxn89d4nk103iqr52mf7qvgsd6s9sdv-dotnet-sdk-2.0.3/bin
patching script interpreter paths in /nix/store/5jxn89d4nk103iqr52mf7qvgsd6s9sdv-dotnet-sdk-2.0.3
/nix/store/5jxn89d4nk103iqr52mf7qvgsd6s9sdv-dotnet-sdk-2.0.3/sdk/2.0.3-servicing-007037/Roslyn/RunVbc.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/h404wfcz8rzzlq8vr4z7plcijwzfci72-bash-4.4-p12/bin/bash"
/nix/store/5jxn89d4nk103iqr52mf7qvgsd6s9sdv-dotnet-sdk-2.0.3/sdk/2.0.3-servicing-007037/Roslyn/RunCsc.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/h404wfcz8rzzlq8vr4z7plcijwzfci72-bash-4.4-p12/bin/bash"
/nix/store/5jxn89d4nk103iqr52mf7qvgsd6s9sdv-dotnet-sdk-2.0.3/sdk/2.0.3-servicing-007037/FSharp/RunFsc.sh: interpreter directive changed from "/usr/bin/env bash" to "/nix/store/h404wfcz8rzzlq8vr4z7plcijwzfci72-bash-4.4-p12/bin/bash"
checking for references to /tmp/nix-build-dotnet-sdk-2.0.3.drv-0 in /nix/store/5jxn89d4nk103iqr52mf7qvgsd6s9sdv-dotnet-sdk-2.0.3...
/nix/store/5jxn89d4nk103iqr52mf7qvgsd6s9sdv-dotnet-sdk-2.0.3

@copumpkin
Copy link
Member

Looks good, thanks!

@copumpkin copumpkin merged commit 4bf2219 into NixOS:master Oct 24, 2017
@copumpkin
Copy link
Member

@kuznero in general, I've seen no space between the colon and the package name, so I think the more common formatting would have been "dotnet-sdk: init at ..."

Also, do you have any plans/ideas about a source build of this? It'd be nice to get it on Darwin too, as well as get the usual patchability benefits we get with source builds.

@kuznero
Copy link
Member Author

kuznero commented Oct 25, 2017

@copumpkin, I have tried it in the first place, but it has a big number of nuget dependences which will only make it more difficult for creating sandboxed package. On the other hand, there is a pre built version of sdk also for Windows and Mac OS, so it should be possible to pull it to and patch (probably differently for Darwin).

Even though it is doable to build sources, I simply thought that it is not practical to spend so much time on it now.

Can you please name benefits for doing it, granted that we will end up downloading many more pre built packages for that? If not download then build with mono, which is not in the perfect condition either in NixOS at the moment.

@kuznero kuznero deleted the pr/dotnet-sdk branch October 25, 2017 05:49
@copumpkin
Copy link
Member

@kuznero it's just generally a preference we have in nixpkgs. If you look, the vast majority of our packages (I'd bet over 99%) are built from source because it affords us more flexibility (we can apply on-the-fly patches to them, they're more pleasant to audit, less trust of other people's build infrastructure, etc.), even if it's more up-front work. Not saying you need to do the work, TBC, but at some point I'd want us to get some good automation around .NET package dependencies so that it isn't much work to make a build like this work. For now this is definitely fine 😄

@kuznero
Copy link
Member Author

kuznero commented Oct 25, 2017

@copumpkin get your point, agree.

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 this pull request may close these issues.

None yet

5 participants