Improve debuggability

[waynevanson]

I think we need a debugger for the file structure because when people use this in their real projects, they may not want to sure their whole repository before and after the change.

Something small that reads the folder and file structure before and after a change.

Motivation for this come from using destiny in a private repository and having some unexplained folder and file renames.

Are there any other features for debugging that might come in handy? I'm pretty sure I can build this.

• [ ] debug flag
  • [ ] add debug flag that logs the following:
  • [ ] pre structure change
  • [ ] post structure change
  • [ ] print all trees, graphs, imports, dependencies and the pretty print directory structure.
  • [ ] git diff with normal and staged changes
  • [ ] flag as boolean prints to stdout, flag with file path prints to file
• [ ] check if git is clean: no changes left uncommitted.

[sQVe]

I think we should add a debug flag which output some information to help debug issues. The hard thing here is to decide what information is relevant in a debug log sense.

Could you give an example on what you found to be unexplained?

[waynevanson]

Could you give an example on what you found to be unexplained?

I had a folder generated that was name after a file, nested in another folder that only had the generated folder. Just a bug that would be easier explained visually.

I think interactive mode would be nice, where it does a dry run, allows you to see the new directory structure tree in the terminal and require approval for the change/s. Pretty sure I've seen this feature posted recommended somewhere.

The hard thing here is to decide what information is relevant in a debug log sense.

The tree structure visually as the first. I'm setting up a repo with the right utils to help out.

In debug mode, should we save logs to the cwd() or to os.home()? I think that it should always save to os.home() + .destiny and in debug mode it goes to cwd() + .destiny.

With the utils, the logs can be saved with the before and after of the folder structure and then a list of "actions" such as older moves, git actions and renames.

[AnatoleLucet]

I think interactive mode would be nice, where it does a dry run, allows you to see the new directory structure tree in the terminal and require approval for the change/s. Pretty sure I've seen this feature posted recommended somewhere.

47?

In debug mode, should we save logs to the cwd() or to os.home()? I think that it should always save to os.home() + .destiny and in debug mode it goes to cwd() + .destiny.

In my point of view it would be better to only save logs in debug mode, or if a flag like the following is given: --logs-output ~/myLogFile.

[waynevanson]

In debug mode, should we save logs to the cwd() or to os.home()? I think that it should always save to os.home() + .destiny and in debug mode it goes to cwd() + .destiny.

In my point of view it would be better to only save logs in debug mode, or if a flag like the following is given: --logs-output ~/myLogFile.

I thought that having destiny save information where the user doesn't see by default would be nice, because we could run destiny [details | logs | info] or something similar to get the logs, even when they're not using debug mode.

This is because when people use destiny, chances are they're not in debug mode.

I'd like to have a similar command to create react app's npx create-react-app --info, so that users can copy and paste the output and we have a standardized way of resolving issues. There's no way to time travel, so saving logs by default out of the user's project scope would be necessary to go back in time.

If users want to raise an issue after they've made changes, they'll have to reverse their changes so they can get a before snapshot, run destiny, and copy their after snapshot. It can definitely become a barrier for when this gets a bit more popular.

[sQVe]

@waynevanson I'm quite strongly against creating automatic logging. It would require a lot of functionality which is outside of the core of destiny. It may also be hard to find which log is relevant when a bug does occur.

I would hope that most information needs will be covered when we dry-run by default. In cases where something goes awry, the user can always revert via version control and rerun with debug flag pointing at a specific location.

[waynevanson]

#47?

Thanks, @AnatoleLucet :)

It may also be hard to find which log is relevant when a bug does occur. I would hope that most information needs will be covered when we dry-run by default.

@sQVe These are valid points. Once dry run is available, an issue template regarding these details should be implemented.

So will the flag be --debug with no arguments? If not, what should it be?

In cases where something goes awry, the user can always revert via version control and rerun with debug flag pointing at a specific location.

If this is to be, I think that destiny should check that there are no pending commits. Currently it does not check this.

Another enhancement: during debug mode, it should also compare the computed graph with the real resulting file structure. If they're not the same, it should post a warning in the console to report it.

[benawad]

So will the flag be --debug with no arguments?

I'm good with that

I think that destiny should check that there are no pending commits.

I could see doing this, and it being a confirmation message "You have some uncomitted changes, are you sure you want to run destiny?"

Another enhancement: during debug mode, it should also compare the computed graph with the real resulting file structure. If they're not the same, it should post a warning in the console to report it.

I like this in non debug mode too, it's good to alert the user when something doesn't go right.

[sQVe]

So will the flag be --debug with no arguments? If not, what should it be?

I think --debug should output information and --debug $HOME/log or --debug=$HOME/log also outputs to file

[AnatoleLucet]

Feature shipped in 0.5.0. :tada: If something is missing, comment it and I'll reopen.