You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now if I import a file, and define a target with the same name as one in the imported file, the target will merge and override anything. This merging and not wholesale replacement makes this operate something like the inherit_from directive; in a sense, the new target is inheriting the old one and then just overriding individual values.
This seems useful/powerful at first, but it's confusing; it leads to weird behavior, like if you define a target that inherits from one of these targets, then the location of the definition changes how the target is built; if defined in the importing file, it uses the local version of the target, but if defined in the imported file, it uses the imported version.
I think it will be better just from a user confusion perspective to disallow importing targets of the same name. If you want to inherit, you have to declare that using inherit_from. This also makes it more explicit that what you see in a given target is all there is; there's no possible "shadow inheritance" from an imported file that is not immediately visible.
This will simply the use case of having an imported file declare a target that inherits from a target declared in the importing file, which useful for parameterizing some re-usable targets.
The text was updated successfully, but these errors were encountered:
Right now if I
import
a file, and define a target with the same name as one in the imported file, the target will merge and override anything. This merging and not wholesale replacement makes this operate something like theinherit_from
directive; in a sense, the new target is inheriting the old one and then just overriding individual values.This seems useful/powerful at first, but it's confusing; it leads to weird behavior, like if you define a target that inherits from one of these targets, then the location of the definition changes how the target is built; if defined in the importing file, it uses the local version of the target, but if defined in the imported file, it uses the imported version.
I think it will be better just from a user confusion perspective to disallow importing targets of the same name. If you want to inherit, you have to declare that using
inherit_from
. This also makes it more explicit that what you see in a given target is all there is; there's no possible "shadow inheritance" from an imported file that is not immediately visible.This will simply the use case of having an imported file declare a target that inherits from a target declared in the importing file, which useful for parameterizing some re-usable targets.
The text was updated successfully, but these errors were encountered: