No SCons symbols in SConstruct to enable IDE's etc to better handle SConstructs/SConscript.

[marcinn]

Nothing from scons is imported in SConstruct file. This makes SConstruct an invalid python script. This is not a python script. Linters does not work. Also nobody knows which object / class comes from.

Also there is sys.path mangling and globals magic, which makes this package incompatible with all python tools (not mentioning good practices in python programming).

[mwichmann]

And the point is?

SCons is a Python program, whose operation is dictated by the instructions, using Python as the programming language in an SConstruct file. That's not the same as an SConstruct itself being a complete Python program.

Yes, there's a lot of fiddling, some of us think that in the context of how Python code is written in 2024 it's overly "clever" and makes some things harder to understand (certainly if you're working on SCons code itself). I will jokingly say that "your list is incomplete" - there's a lot of magic that happens with factory functions of the same name as the class you think you're directly instantiating, and places where methods are renamed in flight, and other stuff that makes things hard to trace - in the SCons code. Those don't actually make it harder to write a build system in SCons, though (in my opinion), they're things that happen behind the scenes.

Would love to have some help getting IDEs to understand the "SCons API" so that bringing up your SConstruct isn't just a screenfull of squiggly lines. There are some contributors chipping away at that but there's clearly much more that could happen.

[marcinn]

And the point is?

The point is to do it right. Refactoring can be difficult, but it's worth it if Scons is going to be a future-proof tool.

That's not the same as an SConstruct itself being a complete Python program.

I just see. Unfortunately you can't have your cake and eat it. All tooling won't work due to outdated hacks under the hood.

"your list is incomplete" - there's a lot of magic that happens with factory functions

I saw some. That's why I said what I said.

[mwichmann]

If you're determined to have some checker tools work on your project, you can attempt something like this in your SConstruct:

from typing import TYPE_CHECKING
...
if TYPE_CHECKING:
    from SCons.Script import *

That's obviously specific to the type checking context, and not something I've personally tested, but might be of some use.

[bdbaddog]

Here's a related enhancement request:
#3210

[marcinn]

I saw this. The whole thing is about making SConstruct a real python script, as stated in the docs. All tools will work with it, not only rare IDEs.

Explicite imports should remove globals magic, and importlib should solve importing other SConstruct files as modules (see import_from_path https://docs.python.org/3/library/importlib.html#importing-a-source-file-directly). Both changes will make Scons user- and stack friendly.

[bdbaddog]

There's nothing preventing you from using explicit imports in your SConscripts.
That said there's a large number of existing builds using SCons without them, so requiring them would break ALL existing builds.

SConscript() does far more than just import.
We're not going to make any such change.

Enabling better interaction with IDE's however has been a goal for a long time.
Closing this bug, since the achievable part of it is contained in the other linked github issue.

Also note, you've ignored the bug template, which requests that you bring any such queries to the users mailing list, discord server, or even a github discussion, before creating an issue.

[marcinn]

Enabling better interaction with IDE's however has been a goal for a long time.

This is not about IDE plugins. You are preventing from using all tools, incl. linters.

There's nothing preventing you from using explicit imports in your SConscripts.

Have you tried this? I tried. It does not work because of false negatives. This is not a solution. Even if I add imports, Scons is still changing sys.paths and not using importlib capabilities. This will never work, because there are ugly, old hacks under the hood, which causes a lot of troubles.

That said there's a large number of existing builds using SCons without them, so requiring them would break ALL existing builds.

I am aware of that. They must just die (read: be upgraded) in few years. That's why I said about the future. There is no other way. And we are talking just about imports, not changing the syntax.

Also note, you've ignored the bug template

I'm sorry, but the scale of the problem is beyond the scope of the bug report template.

[bdbaddog]

That's why we ask you to bring such to a discussion medium and NOT just file an issue first.

I've closed with bug with won't fix.
Sorry we won't be able to make the extensive changes to SCons you feel would be beneficial to your usage.
Locking this issue, if you feel the need to discuss further, please open a discussion.