feat: Rework import generation for stubs.

[Masara]

Closes #38
Closes #24

Summary of Changes

• Reworked the import generation for Stubs. Imports should now be correctly generated. (feat: Rework import generation for stubs. #38)
• Aliases are collected with mypy and are now used to resolve alias origins (feat: Resolve aliasing for imports #24)

Other changes

• Added a "// Todo" for the generated Stubs, if an internal class is used as a type.
• Added "// Todo Safe-DS does not support set types" if a set object is used.
• If booleans where used in Literal Types the first letter was capitalized in stubs, which it should not be.
• Removed the "where" part and lower limits of the Stubs for constrains

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.76%. Comparing base (ced63f3) to head (47077b6).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #50      +/-   ##
==========================================
+ Coverage   98.26%   98.76%   +0.49%     
==========================================
  Files          25       25              
  Lines        1905     2017     +112     
==========================================
+ Hits         1872     1992     +120     
+ Misses         33       25       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ PYTHON	black	16	0	0	1.38s
✅ PYTHON	mypy	16		0	5.96s
✅ PYTHON	ruff	16	0	0	0.04s
✅ REPOSITORY	git_diff	yes		no	0.02s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by

[Masara]

I realized that changes in this PR clash with what we need from Issue #38. Therefore I will revert this PR to a draft and use it as a PR for issue #38.

[Masara]

I'm done with this PR now, too @lars-reimann. Could you check this?

[lars-reimann]

Yes, probably tomorrow. Could you add a summary of changes?

[lars-reimann]

We also need a syrupy extension and a pytest fixture for stubs (see this example). This way all created stubs get their own file with the correct extension, instead of mixing them all together in one ambr file.

[Masara]

@lars-reimann I fixed how the import paths are generated for stubs, now it should be correct. There was just one case where I wasn't sure how to handle it: If we have an import from another package, how should it look like?
This

@PythonModule("various_modules_package.function_module")
package variousModulesPackage.functionModule

from tests.data.main_package.another_path.another_module import AnotherClass

or this

@PythonModule("various_modules_package.function_module")
package variousModulesPackage.functionModule

from mainPackage.AnotherPath.AnotherModule import AnotherClass

?

Currently the first case is implemented. If it's correct like this, you can review and hopefully close this PR.

[lars-reimann]

The second option is correct, assuming the file containing AnotherClass looks something like this:

@PythonModule("does not matter for imports in Safe-DS")
package mainPackage.AnotherPath.AnotherModule

class AnotherClass

The part between from and import must always be equal to the name of the Safe-DS package you want to import from.

[Masara]

@lars-reimann But we are assuming that we did not create the "mainPackage" Stubs yet and don't know where the mainPackage files are. What I concretely mean is, how do imports look like, if we import classes from other packages? Packages we perhaps did not create stubs for? The problem here is that we don't know how the package is named, like in the tests.data.main_package.another_path.another_module.AnotherClass example. Mypy gives us this path to the class, but we actually don't now that "main_package" is the package. Or should I just assume that because our current package, which we are creating stubs for, has the path tests.data.out_current_package.... that we can slice of the tests.data part for tests.data.main_package...., too?

[lars-reimann]

Say we are creating stubs for the package a and are currently working on a Python module with the following content:

from b import SomeClass

def f(p: SomeClass)

Then we also need to create some stub for the class SomeClass, or we can't use it. So limited stubs must be created for the declarations of other packages that package a depends on.

For this PR it's sufficient to completely remove such imports, but please create an issue that stubs must be created for referenced declarations in other packages.

[Masara]

@lars-reimann If I remove those imports for this PR, what about the types that use the imported classes? Should I removed them, too, for the time being?

[lars-reimann]

No, keep the types.

[Masara]

@lars-reimann I removed the imports and created issue #66. You can proceed with the PR review.

[lars-reimann]

🎉 This PR is included in version 0.2.0 🎉

The release is available on:

• v0.2.0
• GitHub release

Your semantic-release bot 📦🚀