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

Cut all dependencies from Myriad.Sdk #174

Merged
merged 1 commit into from
Feb 13, 2024

Conversation

Smaug123
Copy link
Contributor

@Smaug123 Smaug123 commented Feb 7, 2024

The point is that while Myriad itself has strict requirements for which FSharp.Core, FCS, Fantomas versions it's using, there's no need to propagate those requirements to consumers who merely want to invoke Myriad. (This is a pretty serious handicap at the moment if you want to use Myriad through MSBuild in a project that also imports FCS at a different version.)

I'm not super confident in the correctness of this change, but I have tested it as follows, which makes me perhaps 75% sure it's correct.

  • Bump the NuGet version specified in Directory.Build.props to a version which doesn't exist (here I use 0.8.9)
  • dotnet build -t:Pack -c Release
  • Add a NuGet.config file to another repo, specifying my local build folder as a NuGet source:
    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <packageSources>
        <add key="LocalSource" value="/Users/patrick/Documents/GitHub/myriad/bin/nupkg" />
      </packageSources>
    </configuration>
    
  • Bump that other repo's Myriad.Sdk version to the one specified in step 1
  • NuGet restore that other project, verifying that my local NuGet cache's artefact is identical to the one built in step 2 (md5 ~/.nuget/packages/myriad.sdk/0.8.9/myriad.sdk.0.8.9.nupkg and md5 bin/nupkg/Myriad.Sdk.0.8.9.nupkg)
  • Observe that the version of the Myriad tool in my local NuGet cache does indeed contain all the dependencies necessary to run the tool, rather than some kind of symlink (ls -la /Users/patrick/.nuget/packages/myriad.sdk/0.8.9/tools/net6.0/any/Fantomas.Core.dll, for example)
  • Build my other project, verifying that Myriad is invoked from the new version (that is, the build emits lines of the form dotnet "/Users/patrick/.nuget/packages/myriad.sdk/0.8.9/build/../tools/net6.0/any/Myriad.dll" --inputfile …)
  • Verify that my build has succeeded
  • Verify that NuGet reports no dependencies from the new Myriad SDK: Screenshot 2024-02-07 at 00 36 12

@7sharp9
Copy link
Collaborator

7sharp9 commented Feb 13, 2024

Im sat thinking how this stuff is supposed to work...

I think the stuff the sdk needs is merged in via the command like so there is no direct dependecy as the paket import suggests, I think :-/

@7sharp9
Copy link
Collaborator

7sharp9 commented Feb 13, 2024

<Exec Command='dotnet mergenupkg --source "$(NupkgsDir)/Myriad.Sdk.$(Version).nupkg" --other "$(NupkgsDir)/Myriad.$(Version).nupkg" --tools --only-files' />

So technically the myraid package is a dependency but for sdk use we smush it together, I think this was a limitation with the tools stuff but I forget now...

@Smaug123
Copy link
Contributor Author

I think people writing plugins should depend on Core, not SDK; and I haven't yet found a reason SDK needs any deps, because they all seem to be packaged into the tool without reference to the nuget cache, in my testing.

@7sharp9
Copy link
Collaborator

7sharp9 commented Feb 13, 2024

Yes, mergenupkg merges the two packages.

@7sharp9 7sharp9 merged commit d51fdd8 into MoiraeSoftware:master Feb 13, 2024
3 checks passed
@Smaug123 Smaug123 deleted the snip-deps branch February 13, 2024 19:22
@Smaug123
Copy link
Contributor Author

Ah sorry, I misunderstood your previous post - thanks!

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.

2 participants