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

Unhelpful/misleading error message when inporting fails due to missing dependency #1859

Open
3 tasks done
LeeReid1 opened this issue Jan 2, 2025 · 2 comments
Open
3 tasks done

Comments

@LeeReid1
Copy link

LeeReid1 commented Jan 2, 2025

Prerequisites

  • Are you running the latest version?
  • Are you reporting to the correct repository?
  • Did you perform a cursory search?

Description

Importing fails in scenarios where a base class exposes a virtual properties that is in a nuget package and the library was built but not published.

This occurs even if that property is marked [CLSCompliant(false)].

The class that exposes that property often will import just fine, and some but not all classes that derive from it will import successfully. I've yet to decipher the pattern.

The main issue is that the error message does not identify with useful information what is wrong. It simply cannot import the type exposing the property.

Steps to Reproduce

  1. In C#, create a (generic?) class that exposes a public virtual property with type that comes from a nuget package.
  2. Derive from this class a (non-generic?) child class
  3. Build your solution
  4. Link IronPython to the resulting DLL
  5. Try to import the type in IronPython

Expected behavior:

  1. ipy identifies the dependency on a nuget package (potentially not technically possible) OR
  2. ipy produces a meaningful error that states the type exposed by the property cannot be found

Actual behavior:

A non-helpful error message that it cannot import one or more classes deriving from the base class that exposes the property

Work around / Solution

Publish the C# DLL, don't just build it. This should have been done in the first place - my error - but ipy gives such an unhelpful error message that it has cost a lot of development time to discover the issue.

Version Information

IronPython 3.4.2 (3.4.2.1000)
[.NETCoreApp,Version=v8.0 on .NET 8.0.11 (64-bit)]

@slozier
Copy link
Contributor

slozier commented Jan 4, 2025

I tried to reproduce this but without success. Perhaps I'm missing something (or not following the repro steps properly)?

Here's my C# library:

using Newtonsoft.Json;

namespace Issue1859;

public class Class1<T>
{
    public virtual JsonTextWriter? Writer {get;}
}

public class Class2 : Class1<string> { }

Then in IronPython I can import Class2 without issues. If I try to use it I do get a FileNotFoundError with the expected error message:

FileNotFoundError: [Errno 2] Could not load file or assembly 'Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified.

Any suggestions to try and break it?

@LeeReid1
Copy link
Author

LeeReid1 commented Jan 5, 2025

Hey,

Thanks for taking a look into it.

I have since altered the code that lead to that exact example and not kept the old version, but something similar is as follows.

C# Code. TorchSharp is a NuGet package. Canary is there for a sanity check.

namespace FlipProof.Torch;

public class Canary { }

public abstract class BobBase
{
   [CLSCompliant(false)]
   public TorchSharp.Reduce MyProperty { get; init; }
}


public sealed class Bob : BobBase
{ }

Publish then and delete the torchsharp dll or, I suppose, just build the code and check torchsharp hasn't been copied into the bin dir.

Then in python

import clr
import sys
import os

csharpLibraryDir = path-to-the-bin-dir-for-c#
sys.path.append(csharpLibraryDir)
clr.AddReferenceToFileAndPath("FlipProof.Torch")

from FlipProof.Torch import Canary # Passes
from FlipProof.Torch import Bob # ImportError: Cannot import name Bob
from FlipProof.Torch import BobBase # ImportError: Cannot import name BobBase

then call
ipy <name of your python file>

Some important notes:

  • both the child and base classes fail to import here, which differs from my initial report. Both have been seen.
  • In this example, virtual doesn't make a difference. In my other code, removing virtual solved the issue
  • I have an example that will fail in the way I said originally but the codebase is much more complicated and so I don't think it's a good starting point...
  • If torch.Size is changed to a reference type, no error occurs

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

No branches or pull requests

2 participants