On Thursday, 2 July 2015 at 18:28:50 UTC, Russel Winder wrote:
On Tue, 2015-06-30 at 18:20 +0000, John Colvin via Digitalmars-d
Ditched distutils in favour of dub. This is easier for me to
maintain and fits much better with the rest of the D ecosystem
I am not convinced by this, though cleary my feeling carry no
weight in decision making :-)
For building C, and C++ extension (and indeed Chapel ones) it
is assumed distutils will be used, allowing for:
python3 setup.py build
python3 setup.py install
SCons can do this but every one demands distutils. Can dub
really replace distutils for installing extensions as well as
building them? Will people installing extensions be prepared to
switch to a non -standard system? Whilst perhaps they should,
they won't. I fear that without a distutils installation, the
extension will never be installed outside the development team.
It's not the D community that must be convinced, it is the
What is the benefit from using distutils for working with D in a
notebook? There are two standards - the Python one, and the D
one. The advantage of using dub is that it becomes wonderfully
easy to pull in D projects from code.dlang.org and to compile
your own work developed under dub. (And dub itself continues to
improve). Linking to a D project of decent complexity via
distutils is not my idea of fun.
I do agree that for pyd itself it would be nice to retain the
option of distutils (although I would love to see dub added also),
One should look at this as an alpha, extremely promising project.
It is not any rough edges that are important at this stage, but
that it has been done at all (in a form that is already very
The set of people that want to use computers to explore larger
data sets than lately considered comfortable in an iterative
manner is not small, even confining It just to finance. It's of
real value to be able to hook in to a proper back end that
manages market and static data, with also any data processing and
analytics also in D, and then to have a pretty and friendly front
end that can just talk to this code on the back with minimal
messing around to get there. It's also very nice to have both
Jupyter and an Excel spreadsheet at windows onto the data on your
local machine or in the enterprise cloud.
The frictions to starting to play with D in a notebook are much
lower than going via the command line, so I really am not sure if
we should be worried about making it marketable at this stage
rather than useful for doing real work. It's potentially a nice
debugging tool where you are trying to make sense of things that
don't tidily fit in a debugging window, and where there is just
too much stuff to do it via writefln or logging without putting
lots of effort into the infrastructure to find events first.
I do like the simpler syntax (than PyD). One question is whether
you need to wrap every member of a struct.
But it's a very useful start as it stands.