You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Zingg is a bit magical to me. Learning Spark and different strategies to cluster the entities is to be solved as a software problem - so non-experts like myself can employee a tool, and the evolution of Zingg can take a software path over a systems engineering path. I love it.
Current the ergonomics are a bit rough (in this < 1.0 version). Using Zingg is akin a a craftsman workbench. We enter a Docker container and look up options either reading zingg.sh or via the website and step through. For importing and exporting labeling we use pySpark directly.
Once an engineer has knowledge of the tech and the process, they can adapt, but a better UX would lower barriers and facilitate correct on-going use.
I am not running Zingg in a big compute env and will used on small batches in a flow. For me the single container runtime is perfect for both interactive training and the matching phases.
Describe the solution you'd like
A CLI with intentional UX design would resolve these concerns and help make Zingg fly. Implementation wise, I would appreciate a wrapper that treats the Docker container as a CLI with tab completion, hints, exact error messages, etc. With a schema for the config in #183 the CLI can validate the config. The config could also specify a Zingg version or alternative Docker tag - the cli would have a separate lifecycle and versioning. I like podman and given that Docker is not the only runtime anymore it should be generic and not be coupled to Docker API specifically.
Describe alternatives you've considered
Lots of ways to solve this, just putting the UX concern out there.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Zingg is a bit magical to me. Learning Spark and different strategies to cluster the entities is to be solved as a software problem - so non-experts like myself can employee a tool, and the evolution of Zingg can take a software path over a systems engineering path. I love it.
Current the ergonomics are a bit rough (in this < 1.0 version). Using Zingg is akin a a craftsman workbench. We enter a Docker container and look up options either reading zingg.sh or via the website and step through. For importing and exporting labeling we use pySpark directly.
Once an engineer has knowledge of the tech and the process, they can adapt, but a better UX would lower barriers and facilitate correct on-going use.
I am not running Zingg in a big compute env and will used on small batches in a flow. For me the single container runtime is perfect for both interactive training and the matching phases.
Describe the solution you'd like
A CLI with intentional UX design would resolve these concerns and help make Zingg fly. Implementation wise, I would appreciate a wrapper that treats the Docker container as a CLI with tab completion, hints, exact error messages, etc. With a schema for the config in #183 the CLI can validate the config. The config could also specify a Zingg version or alternative Docker tag - the cli would have a separate lifecycle and versioning. I like podman and given that Docker is not the only runtime anymore it should be generic and not be coupled to Docker API specifically.
Describe alternatives you've considered
Lots of ways to solve this, just putting the UX concern out there.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: