On Monday, 18 November 2019 at 12:59:25 UTC, Joseph Rushton
Wakeling wrote:
Cool :-) Since I have also been experiencing a fair bit of
production-use DUB pain in the last year, I really appreciate
your taking action on this.
A few things that would be good to understand up front:
* what are the particular issues with DUB that you want to
address?
- making the codebase cleaner and more functional is
obviously
nice but is at most a means to an end -- what's the
real end
you have in mind?
My reason for making it cleaner is, because I assume this will
give
me a build tool I can fix when broken. And hopefully it has less
bugs to begin with because its cleaner.
- I would imagine getting dependency resolution really
right
would be top of the list -- it would be good to aim to
fix
issues like https://github.com/dlang/dub/issues/1732
That is one thing yes.
- I would personally really appreciate it if you would
make it
a design goal to better separate concerns in terms of
what
DFLAGS are used and why (for example, the fact that
right now
`dub test --build=release` will not actually run
unittests,
as `--build=release` drops the `-unittest` flag)
* are there any particular known issues with DUB that this
definitely
will NOT address?
I'm not sure yet.
* are there any key _breaking_ changes you have in mind?
* where does this stand w.r.t. some of the proposals to break
DUB apart
into more cleanly separated components, e.g. determining
compatible
dependencies, downloading dependencies, building or running
tests ... ?
It is build as a library first. The CLI is just using the library
constructs.
Some concrete feedback on the project as it stands:
* the tickboxes of compatible commands are nice, but it would
be good to
have a more contextualized roadmap, in particular outlining
the design
concerns for core data structures and functionality
- this should probably be in issues rather than the
README, but
it needs to be somewhere, otherwise it's hard for
anyone outside
to identify things they can do
True, I'll work on that.
- it might be nice to use a GitHub project to manage
things so that
us outside folks can identify better what's being
worked on and
what's blocked by what
I already started that, somewhat.
* I don't mind breaking changes in either the config format
or the command
line API if it gets us to a nicer tool, so please embrace
the opportunity
where appropriate
- I can imagine this might be the reason why the aim is
to support
a "tasteful subset" of DUB's features: it means that
others can
be re-implemented in an incompatible but better way
- auto-conversion mechanisms may be preferable to
outright support
for old formats and commands
* I really recommend trying to start writing clean, clear
commit messages
from the very start -- think of this as another form of
code documentation
that communicates to all interested readers the intent and
considerations
behind any particular change to the codebase. This makes
it much easier
for outsiders to get a clear understanding of the project
and get into the
habit of contribution
- right now, pretty much all the commit messages read
like spontaneous
notes where even YOU won't remember the whys or
wherefores in a few
months' time
I know, I'll try to do better
- long term it saves a LOT of time when trying to look
back and understand
"Why did we do things that way?" -- particularly useful
when trying to
fix some subtle design bug
* for the same reasons, really try to provide good
documentation and comments
for all code from the start -- this really makes it much
easier for anyone
interested to grasp the major design concerns and get
contributing
Here is disagree, to a degree I consider comments a code smell.
If I have to write them, I failed to convey the information
needed to understand the code in the code.
* these concerns are going to be strongest for the key data
structures and
algorithms -- please make sure these are REALLY documented
well, from the
very start
Hope all of that's helpful, and best wishes for taking this
forward -- I will try to help as I can, but time right now is
very constrained ... ;-)
Thanks & best wishes,
-- Joe
Thank you
