Skip to content

Conversation

suhsteve
Copy link
Member

@suhsteve suhsteve commented May 13, 2020

This extension will add a a middleware to the dotnet-interactive session when this nuget is added via #r "nuget: Microsoft.Spark.Extensions.DotNet.Interactive".

For every code submission, the middleware will add the compiled assembly (before the current code has been processed) to the spark context by calling SparkContext.AddFile(...).

In addition to this, we also add any nuget package dependencies that the current session depends on to SparkContext.AddFile(...)

PackageHelper identifies dependent nuget packages and generates the necessary files for Microsoft.DotNet.DependencyManager.DependencyProvider

Please see #515 for additional details.

@suhsteve suhsteve changed the title [WIP] dotnet-interactive assembly extension dotnet-interactive assembly extension May 15, 2020
@suhsteve suhsteve force-pushed the dotnetinteractive_extension branch from 9bd0f0e to d7960f9 Compare May 29, 2020 07:19
string assemblyName =
AssemblyLoader.NormalizeAssemblyName(preCompilation.AssemblyName);
string assemblyPath = Path.Combine(tempDir.FullName, $"{assemblyName}.dll");
if (!File.Exists(assemblyPath))
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we handle the case where the assemblyPath already exists?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it's safe to remove now that we have the command is SubmitCode check.

Copy link
Contributor

Choose a reason for hiding this comment

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

If this is an unexpected case, should we just throw and fail early?

Copy link
Member Author

@suhsteve suhsteve Jun 4, 2020

Choose a reason for hiding this comment

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

Previously, other dotnet-interactive internal calls were hitting the middleware, and running the dll emitting logic and this caused it to try to emit duplicate assemblies. But I believe with the command is SubmitCode we should be okay. But to be safe we can readd the check and not run the middleware.

if (!IsPathValid(nugetFile.FullName))
{
// Copy the nuget file to a location that works with
// SparkContext.AddFiles(..)
Copy link
Contributor

Choose a reason for hiding this comment

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

why is this? (e.g., why wouldn't it work)?

Copy link
Member Author

Choose a reason for hiding this comment

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

The original nupkg file can be in a location like, C:\Users\user with spaces\.nuget\packages\package.name\version\package.name.version.nupkg and that would not work with SparkContext.AddFiles(..) with a spark version lower than 3.


foreach (FileInfo file in files)
{
if (!file.Exists || s_filesCopied.Contains(file.Name))
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be easy to debug the !file.Exists case if we ever hit it?

Copy link
Member Author

@suhsteve suhsteve Jun 3, 2020

Choose a reason for hiding this comment

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

We can remove this check and trust DirectoryInfo.EnumerateFiles(..).

public IEnumerable<ResolvedNuGetPackage> GetPackagesToCopy()
{
PackageRestoreContext restoreContext =
((ISupportNuget)KernelInvocationContext.Current.HandlingKernel)
Copy link
Contributor

Choose a reason for hiding this comment

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

should ISupportNuget be passed into the constructor of this class? In that case, is this class also testable now (not sure how hard it is to mock ResolvedPackageReference)? And I think this function can move to PackageHelper? (I don't get the abstraction layers of PackageResolver vs PackageHelper)

Copy link
Member Author

Choose a reason for hiding this comment

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

Originally moved out logic from PackageHelper into PackageResolver to do unit tests. Couldn't mock ISupportNuget, because PackageRestoreContext.ResolvedPackageReferences isn't a virtual property.

Moved logic back into PackageHelper and instead wrapping the ISupportNuget ... PackageRestoreContext.ResolvedPackageReferences call.

@imback82 imback82 added the enhancement New feature or request label Jun 4, 2020
Copy link
Contributor

@imback82 imback82 left a comment

Choose a reason for hiding this comment

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

LGTM except for few minor/nit comments.


namespace Microsoft.Spark.Extensions.DotNet.Interactive
{
internal class PackageHelper
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a better name than Package'Helper'? :)

Copy link
Member Author

Choose a reason for hiding this comment

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

hmm.. I'm bad with naming. How about Package'Resolver' ?

Copy link
Contributor

Choose a reason for hiding this comment

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

yea sounds good to me.

string assemblyName =
AssemblyLoader.NormalizeAssemblyName(compilation.AssemblyName);
assemblyPath = Path.Combine(dstPath, $"{assemblyName}.dll");
if (!File.Exists(assemblyPath))
Copy link
Contributor

Choose a reason for hiding this comment

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

I thought this was a critical error scenario no?

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think it's expected. Should we log an error or throw an exception ?

Copy link
Contributor

Choose a reason for hiding this comment

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

let's throw an exception to fail fast


private string GetPathRelativeToPackages(string file, DirectoryInfo directory)
{
string strippedRoot = file
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add one example for this function please?

Copy link
Member Author

Choose a reason for hiding this comment

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

Should I move the examples that are at the callsite of GetPathRelativeToPackages(..) and add it to the method description instead ?

Copy link
Contributor

Choose a reason for hiding this comment

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

oh, you can just add it here.

Copy link
Contributor

Choose a reason for hiding this comment

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

just relevant example related to this function should be fine.

@suhsteve
Copy link
Member Author

@imback82 addressed your comments. LMK if they look fine.

probingPaths)
});

var packageResolver =
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: no need to break now?

Copy link
Member Author

Choose a reason for hiding this comment

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

changed.

imback82
imback82 previously approved these changes Jun 12, 2020
Copy link
Contributor

@imback82 imback82 left a comment

Choose a reason for hiding this comment

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

LGTM, thanks @suhsteve!

@suhsteve
Copy link
Member Author

@imback82 actually don't merge yet. The ISupportNuget interface has been changed with the latest version of dotnet-interactive.

@jonsequitur
Copy link

Also, please be aware of and weigh in on: dotnet/interactive#512.

@imback82
Copy link
Contributor

@suhsteve the tests keep failing with timeouts (I retried 3 times). Can you check?

@suhsteve
Copy link
Member Author

@suhsteve the tests keep failing with timeouts (I retried 3 times). Can you check?

I've seen this happen quite a few times with the recent PRs. I think something fishy is going on with the test pipeline.

@imback82
Copy link
Contributor

I don't see the failures from recent builds here? https://dev.azure.com/dnceng/public/_build?definitionId=459&_a=summary

@suhsteve
Copy link
Member Author

I don't see the failures from recent builds here? https://dev.azure.com/dnceng/public/_build?definitionId=459&_a=summary

I think it's an issue with DeltaTable.Foreach , issue #333 . If we get lucky then it will use the same thread that has the activeThreadSession .

@imback82
Copy link
Contributor

Well, I saw multiple timeouts (>60 mins). Let's see what happens with the latest one.

@imback82
Copy link
Contributor

You can check attempt 3 and 4.

@imback82
Copy link
Contributor

I think we need to merge #524 soon.

@elvaliuliuliu
Copy link
Contributor

I am also seeing the issue of DeltaTable.Foreach while testing backward compatibility. For instance, bc test failed in the recent PR #536 and it happened when testing #524 as well.

@imback82
Copy link
Contributor

The latest failed with Delta error. But if you look at the runtime, it could not have finished within one hour. You can compare the runtimes with https://dev.azure.com/dnceng/public/_build/results?buildId=679547&view=logs&j=ca395085-040a-526b-2ce8-bdc85f692774. Any changes in this PR could cause the regression?

@suhsteve
Copy link
Member Author

There shouldn't be. The last 4 commits successfully passed tests.
643db70
a73fabb
914a576
2259289

The checkins from yesterday shouldn't have increased the running time.

@imback82
Copy link
Contributor

Maybe build agent changed? I see that E2E for Spark 2.3.x is taking more than 2 minutes instead of <1 minute even in master: https://dev.azure.com/dnceng/public/_build/results?buildId=685678&view=logs&j=ca395085-040a-526b-2ce8-bdc85f692774&t=c58e8551-6b20-5658-7a75-0283b3f97acb

@imback82 imback82 merged commit 4be3dce into dotnet:master Jun 13, 2020
@suhsteve suhsteve deleted the dotnetinteractive_extension branch June 13, 2020 04:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants