Use natural order of task names when listed

[vlcinsky]

$ doit list
buildhtml  Build HTML documentation.
buildpdf   Build PDF documentation.
publish    Publish documentation to FTP.
spell      Spell document source files.

Tasks are today listed in alphabetical order.

As seen, it can look quite confusing and user would appreciate natural order:

$ doit list
spell      Spell document source files.
buildhtml  Build HTML documentation.
buildpdf   Build PDF documentation.
publish    Publish documentation to FTP.

I guess, changing order of listed items is not likely to break anything and I would prefer do it this way by default. Author has good control of order of tasks definitions in dodo file.

If alphabetical order would be (sometime) required, we could add a key "listorder" into DOIT_CONFIG.

I had similar issue with Click https://github.com/pallets/click/issues/513 (and I managed to resolve it).

[FrankStain]

@vlcinsky , just my 5 cent for this issue. Indeed, the different options to sort the list of command would be welcome.

Actually, the alphabetical order is much useful when list of your tasks counts above hundreds of names. I managed to use doit in large scalable build systems. I definitely sure that default alphabetical order of listed tasks is more useful instead of natural one. More over, large systems are build from lot of modules containing the tasks, so there just no one knows the natural order of tasks.

Where that block of tasks beginning from 'S'?.. Oh s**t, it is not sorted by alphabet!

Also, alphabetically ordered list of tasks is much helpful in auto-complete tools. And you know it, there are no time at all for additional sorting in case of auto-complete. The word have to be completed just as typed.

So, my opinion here is that the order have to be alphabetical by default. But, indeed, the configuration option would be good, as well as command-line argument for list command.

[schettino72]

I agree with @FrankStain

keep default alphabetical order, add support to natural order.

[vlcinsky]

Great comment @FrankStain

I wonder, where so high number of tasks in your case comes from, I can think of two sources: number of specific tasks and number of files (or other types of items, which usually populate subtasks).

Regarding tab completion: I consider tab completion distinct from listing and the purpose is a bit different so alphabetical order seems to be the best option.

Regarding sorting:

• current alphabetical shall be the default one
• the tasks listed may have one or two parts (basename and name). Shall we allow different sorting rule for each part? I can imagine, that basenames (mostly related to type of actions taken) could go in natural order while subtasks (mostly related to files) could go alphabetical).
• methods to control sorting shall be as usuall: DOIT_CONFIG, command line option, doit.cfg and env var.

[FrankStain]

@vlcinsky , i'm professional game developer. Also, i support my own huge game framework written on C++. :)

So, the large scalable build systems are the game building automation tools. It consists of game binary image builders for different platforms, including cross-compilation of source code and source code generation from some DSL schemes. Also it consists of resource generators, where a lot of resource types (dozens of types: textures, 3d objects and scene graphs, sounds, database and state machine raw data) have to pass through dozens of compilation steps. After all, such build system consists of dynamic testing tool, which makes some tests on build target before make it published for Draft usage, QA or Retail customers. And, yep, publishing/QA deployment also implemented as part of build system.

Just imagine you need to read PNG into pixelmap, compress it into ETC2, ATCI, S3-TC5/BC3 and PVR-TC4, after what each of compressed texture should be placed into different resource pack, obfuscated and encrypted. And all is done by different tasks, cuz i can read textures even from database, zip-file or other pack and may not wish to compress it into some formats. Each sound should be loaded from PCM, converted into MP3 or OGG and linked with each sound mixer where it used, after what it also have to be placed at proper resource pack, obfuscated and encrypted. 3d location compilation process is about two hundreds tasks on just objects, not files. It's most complex resource pipeline in build system.

doit is well designed tool for such purposes, i think.

[schettino72]

@FrankStain nice, are you still using doit in the build process?

I guess this makes a success story :smile:
Would it be OK for you if we add your story to http://pydoit.org/stories.html ?

[vlcinsky]

@FrankStain that's really impressive.

If we ever set up doit gallery, I will definitely ask you to consider contribution.

And @schettino72 is right, the text you just wrote would perfectly fit on doit Success stories page.

[FrankStain]

@schettino72 , yep, you're free to share my text as success story. :)

I'm restricted by NDA to reveal valuable details of my work. I'll think about sharing some details of my own framework.