Viddy as an importable package.

[anvial]

This PR should allow importing Viddy tool as a lib in other Golang projects.

Also, I've added the PreconfiguredNewViddy func to avoid additional dependencies in 3-party projects.

I suppose this is a good structure to use both:

• as a library
• as a binary

Ready for comments and discussions.

[gedw99]

thanks @anvial

The project has a dependency on the TUI lib. I am planning to use viddy in a WASM project where it is cross compiled using tinygo and then run it in the browser. So I was wondering if the project can be structured so that the TUI and the core viddy are separated ?

cc @sachaos

[sachaos]

@gedw99 It is interesting that you are going to run it in WASM.
I have a few questions. (I don't have any WASM experience, so sorry if I'm wrong.

• What would be the use case in WASM? viddy executes a command and outputs it, but what would it output instead?
• If we don't depend on the TUI library, what will we depend on instead?

[sachaos]

To reduce the dependency of the viddy lib, I think it will be great if we can remove dependency of the viper from lib.
What do you think?

[gedw99]

+1 on removing viper from the lib. assume it will stay in the TUI ... ?

[gedw99]

Hey @anvial excellent questions and thanks for asking. Let me know if this explains things better ...

• What would be the use case in WASM? viddy executes a command and outputs it, but what would it output instead?

Service workers inside a browser are essentially http servers. You can write them in golang and compile them to wasm. So they are processes, just like you have processes on your laptop.

I am building a quasi IDE in golang, and want to use viddy in exactly the same way. This quasi IDE is in golang, and compiled to run as a GUI.

The same is also true on the server side. Checkout https://github.com/tetratelabs/wazero.
You can compile your golang to wasm, and get instant starts and sandboxing.
Viddy can then used with wazero to inspect what is going on with the golang / WASM running on a local or remote server.

• If we don't depend on the TUI library, what will we depend on instead?

What i propose is to have viddy as a golang package. Then any GUI / TUI can import it and use it.

I am using https://github.com/gioui to build the GUI that does what the current TUI does.
It can run on Web, Desktop and Mobiles. Its 100% golang code just like the TUI.

[sachaos]

@gedw99 Thank you.
It is nice to remove the dependency and user can change the view.

But currently, viddy depends on rivo/tview (TUI lib) heavily.
And I think it would be hard.
I don't think removing rivo/tview should be done in this PR.

If you want to remove rivo/tview from viddy lib.
Feel free to submit the PR.

[gedw99]

I don't think removing rivo/tview should be done in this PR.

@sachaos your right. Its best to do in later PR.

I will make an issue now for it so we can swing back to it later.

here is the Issue: #78

[anvial]

@sachaos,

what is your feedback about current PR? What do you think about changing the structure?

I also need your advice and suggestion on how to implement the --version flag, because looks like this PR has broken it...

[sachaos]

@anvial About structure, please refer to my idea of importable package of viddy.
(This is WIP and not working, but the interface would be that.
https://github.com/sachaos/viddy/blob/feature/refactoring-viddy/pkg/viddy/viddy.go
I'm happy if you like this and follow that in this PR.

About, version and help.
Please parse os.Args by newConfig() in main.go, and handle that in main.go.
Then pass the Config struct to NewViddy().
Then the viddy lib package will no longer depends on viper.

[anvial]

@sachaos

https://github.com/sachaos/viddy/blob/feature/refactoring-viddy/pkg/viddy/viddy.go

Your approach looks clean and smooth. I think this is the right way to implement it.

How can we help the refactoring-viddy branch?

[sachaos]

@anvial If you already have viddy on the juju side, making viddy importable may not be an urgent issue. In that case, I would appreciate it if you could wait for my work.

If there are other requests and it should be importable, I think it is possible to imitate only the viddy interface of that branch and leave the content unrefactored on this PR.
Then, even if I refactor later, the interface should not change, so I think that the users of the library will not be bothered.

[anvial]

That's reasonable,

Thx so much for your work!

PS: Looking forward to switching the sachaos/viddy repo after the needed functionality is introduced.