Hi,
Is the nimscript/nimble integration possibly repeating the mistakes of Python's setup.py? The fact that setup.py is code has led to problems e.g it's impossible to reliably determine the dependencies of a package unless you are running within the target environment.
Has something similar to environment markers been considered instead?
Ollie
Using a Turing complete language, as you point out, has the disadvantage that is not statically analyzable.
On the other hand, there is a very good reason to use nimscript in nimble, which is writing tasks. Usually, one needs two things to build something:
Moreover, since tasks naturally require dependencies - say for compiling, the latter depends on the former. Hence one could have either a task runner based on nimscript that integrates nimble, or add nimscript support to nimble itself.
Notice that a task runner that does not make use of nimble would not work (such as nake).
I think adding nimscript support to nimble was the most pragmatic option. In fact, sbt and leiningen take a similar approach, the configuration being written in Scala and Clojure respectively.
Python setuptools, on the other hand, do not allow the definition and running of custom tasks, so there is no good reason for them not be declarative
On the other hand, there is a very good reason to use nimscript in nimble, which is writing tasks
Yes, but does this require mutable package metadata?
Python setuptools, on the other hand, do not allow the definition and running of custom tasks
https://pythonhosted.org/setuptools/setuptools.html#extending-and-reusing-setuptools
Plus it's python - you can monkey-patch almost anything!
so there is no good reason for them not be declarative
Legacy support is a pretty compelling reason :-)
Yes, but does this require mutable package metadata?
No, of course not. It's just that once you have a Turing complete language to describe the build (which is useful for other reasons,as I outlined above), you cannot guarantee anymore that dependencies are statically analyzable. I don't think it will be a problem in practice - I would guess that most (all?) packages use literal calls require "someDependency". That could even be enforced by making the arguments of require of type string[lit].
https://pythonhosted.org/setuptools/setuptools.html#extending-and-reusing-setuptools
Great, I did not know about this! :-)