On Mon, Oct 1, 2012 at 12:40 AM, Donald Stufft
On Sunday, September 30, 2012 at 6:50 PM, David Cournapeau wrote:
I am not sure I understand the argument: whatever the syntax, if the feature is there, you will have the same problem ? The fact that it is used by existing solutions tend to convince me it is not a problem (cabal works much better than distutils/etc... in pretty much every way, including installing things with dependency from their package servers, not to speak about RPM).
I have a site that pulls data from python packages, one of my problems of late has been pulling requirements data out of a setuptools setup.py. Simply fetching the data for my current system is simple, however because of the use of conditionals that affect the final outcome of the metadata in order to make sure I get a true and complete accounting of all the metadata I would have to anticipate every combination of conditions used inside that file.
Now as far as I can tell, the bento.info conditionals have that same problem except that they have a much narrow scope, so they have a smaller matrix.
How would I given a package that has an ``if os(windows)`` conditional, get a representation of that files metadata as if it were in windows? I would need to override what os(windows) is? Now if this same package also has conditonals for flags, the matrix becomes larger and larger and I need to either create my own custom parser that just ignores or annotates the conditionals or I need to use the official parser and run it through once per item in the matrix to get the "whole story". Am I incorrect in that?
Additionally, conditionals as they are (to my understanding, having never used bento but having read the docs and some of it's source code) implemented in bento complicate the parser and confuse reading a file with understanding a file.
What additional power or benefit does:
Library: InstallRequires: docutils, sphinx if os(windows): pywin32
provide over:
{ "Library": { "InstallRequires": [ "docutils", "sphinx", "pywin32; sys.playform == win32" ] } }
It is obviously exactly the same, it is just different syntax (which is why I don't understand the "fetching requirements" arguments, since whatever is true for bento is true of your format and vice et versa).
Maybe i'm missing some powerful construct in the bento.info that warrants throwing out a lot of hard work and testing of a lot of individuals for these common formats, however I just don't see it in merely providing a simple conditional statement. The ``bento.parser`` package contains ~1700 SLOC now without investigating that terribly deeply I'm willing to bet almost all of that could be thrown out in the use of a standard format.
What I am afraid of is that one will need to add a lots of those markers, not just for requirements, which will lose the point of using a common format. I would also recommend against json, because it does not allow for comments, yaml is much better in that regard.
I know you've mentioned Cabal a lot when talking about bento, and it's obvious it's been a very big influence on your design.
Mostly the syntax, actually. David