Linking by socket indices breaks forward compatibility

[atticus-lv]

System Information

• OS (Windows, MacOS, Linux)
• Blender version
  • 4.4/4.5

Describe the bug
this is what the node Evaluate at index looks in 4.5

in 4.4

blender 4.5 has make changes to the socket index with some node, this problem will cause some socket link error when using codes from older version to 4.5

To Reproduce
Steps to reproduce the behavior:

1. add an Evaluate at index , link the input to some node
2. generate the code in 4.4
3. use the code in 4.5
4. you will see the switch link of this two input

Expected behavior
I am not sure this should be a forward problem problem.

[BrendanParmer]

Apologies for the delayed response, that's rather unfortunate.

NodeToPython's currently setting links by the socket index. In previous versions of Blender, setting links by the node name was unreliable, as you'd get collisions between sockets of different types (for example, the Map Range node in Blender 3.3 had two sockets named "From Min"). I want to say they changed the behavior so that setting links by names was more reliable back around 4.1 or 4.2, but to maintain compatibility with old versions of Blender it wasn't an option to switch over at the time.

That said, Blender's oldest LTS is now 4.2, and the majority of users seem to download NodeToPython from the Extensions Platform, which is 4.2+, so I'm leaning towards deprecating older editions of Blender. I'll create a discussion to see if there's any serious objections to it, but I think at this point better forward compatibility for scripts is probably more important than supporting old Blender versions

[atticus-lv]

Agree.
Also, a new version addon should have the ability to load the old code generate from the older version , a version manage is need. Maybe we should check out how blender store the new changes for links

[BrendanParmer]

I was hoping to give this a proper implementation before v4.0, but unfortunately I've run out of time. Referencing by identifier mostly works, but it seems to fail for nodes with a dynamic number of sockets (group nodes, menu switches, zone inputs, etc.). Not as clean a solution as I was hoping, but still something there to look into