Current Situation
The Target.item is currently treated as the name, the address or the pointer to the actual content or value we want to keep updated by the build. The canonical example is the Path of a file.
This is most clearly seen by the fact that state= and cmd= functions (usually) don't get the Target passed as a parameter, but its item's value, meaning they can change the value the item is pointing to but not the Target's item itself.
Further, the current assumption is that
- the thing we want to keep updated depends on the dependencies
- its address or name is known ahead of time and, in particular, does not depend on the dependencies
An example where this breaks down is when the file's path is provided by an environment variable and we would like to treat the environment variable as a dependency. In this case it is not the content of the file which depends on the dependency, but its path.
Requirement
Provide a means whereby the Target.item, as a pointer to the actual value to keep updated, may depend on the dependencies.
Rationale
One, somewhat weak, argument I encountered goes as follows: If we use
Target(Path(os.getenv("SOMEENV"), name="libout")
assuming that SOMEENV is actually set, the value of SOMEENV ends up in the dependency graph. I like my projects to show the dependency graph on Codeberg, but I don't like to expose my private software setup.
If we could write something along the lines of
liboutEnv = Target(Getenv("SOMEENV"))
Target(lambda getenv: Path(getenv.get()), liboutEnv)
we would only see str(Getenv("SOMEENV")) in the output, which should avoid to provide the actual environment value. But it would obviously require to allow to compute the target's item on the fly,
- after the dependencies are updated
- with the dependencies as parameters
Considerations and Ideas
- If the first argument of
Target is callable, its signature must match the list of dependencies and it must return a T, the generic argument type of Target.
- defining an
@property which calls the callable, if needed, might be just right
# Current Situation
The `Target.item` is currently treated as the name, the address or the pointer to the actual content or value we want to keep updated by the build. The canonical example is the `Path` of a file.
This is most clearly seen by the fact that `state=` and `cmd=` functions (usually) don't get the `Target` passed as a parameter, but its `item`'s value, meaning they can change the value the item is pointing to but not the `Target`'s item itself.
Further, the current assumption is that
- the thing we want to keep updated depends on the dependencies
- its address or name is known ahead of time and, in particular, does not depend on the dependencies
An example where this breaks down is when the file's path is provided by an environment variable and we would like to treat the environment variable as a dependency. In this case it is not the content of the file which depends on the dependency, but its path.
# Requirement
Provide a means whereby the `Target.item`, as a pointer to the actual value to keep updated, may depend on the dependencies.
# Rationale
One, somewhat weak, argument I encountered goes as follows: If we use
```python
Target(Path(os.getenv("SOMEENV"), name="libout")
```
assuming that `SOMEENV` is actually set, the value of `SOMEENV` ends up in the dependency graph. I like my projects to show the dependency graph on Codeberg, but I don't like to expose my private software setup.
If we could write something along the lines of
```python
liboutEnv = Target(Getenv("SOMEENV"))
Target(lambda getenv: Path(getenv.get()), liboutEnv)
```
we would only see `str(Getenv("SOMEENV"))` in the output, which should avoid to provide the actual environment value. But it would obviously require to allow to compute the target's item on the fly,
- after the dependencies are updated
- with the dependencies as parameters
# Considerations and Ideas
- If the first argument of `Target` is callable, its signature must match the list of dependencies and it must return a `T`, the generic argument type of `Target`.
- defining an `@property` which calls the callable, if needed, might be just right