Updates for v0.3

[ydcjeff]

Below are some updates from me for v0.3.

I am thinking to refactor the app into something that users should compose how the training flow should be like by themselves like @sdesrozis proposed in #20.

Summary

We will provide the necessary PyTorch components, and PyTorch-Ignite core components + experiment loggers from contrib.

• Users should choose the components they need by clicking and the respective component will show up in the canvas. (Usage in left area)
• Users should connect the components according to their training workflow in the canvas area. (Usage in center area)
• And users can configure the necessary parameters in the right panel. (Usage in right area)

UI will be divided into 3 sections like:

Components Panel	Canvas	Parameter Panel

We will store the connections between the components and their values in JSON format and we will generate the code from that.

Unresolved questions

There could be some code that we cannot easily generate. For e.g., the process_fn passed to Engine can be different as per tasks and as per users. How should we tackle this?

• Should the function be left for the users to write their own? (If so, it would be hard for our testing)
• Should we generate common baseline code?
• ...

Let me know your thoughts.

@vfdev-5 @sdesrozis @trsvchn @KickItLikeShika @Priyansi

[sdesrozis]

@ydcjeff I do appreciate this idea :) We discussed something similar with @Priyansi. IMO having another view for code generator will be a great improvement !

About the unresolved part, maybe the user could import some pieces of code, for instance process_fn but some handler functions (as decorator) too. What do you think ?

[ydcjeff]

IMO having another view for code generator will be a great improvement !

Do you mean having another url like /create from the current app?

About the unresolved part, maybe the user could import some pieces of code, for instance process_fn but some handler functions (as decorator) too. What do you think ?

Yes, users can freely import and write their own code once the codes are generated and downloaded. But there are some code that cannot be generated that are customized to each user. We could generate common baseline code or left blank so that they can write their own.

[sdesrozis]

Do you mean having another url like /create from the current app?

I have understood the view you suggested was an alternative to the actual. Having a /create url to let the user explore a plug and play approach makes sense to me. However I may have misunderstood what you have in mind.

Yes, users can freely import and write their own code once the codes are generated and downloaded. But there are some code that cannot be generated that are customized to each user. We could generate common baseline code or left blank so that they can write their own.

I think the user's custom code areas should have explicit dependencies from the components panel. Thus, the function's (or handler's) signatures can be generated safely, and the dataflow remains consistent.

[ydcjeff]

Sorry for not making clear. The 0.3 update will replace current 0.2 app.

For the custom code, currently there is no option to write since the code can have error which can be mistaken as our error.

[vfdev-5]

For the custom code, currently there is no option to write since the code can have error which can be mistaken as our error.

I agree, let's leave all user customization to the user

@ydcjeff how about cherry-picking also something from #177 for v0.3.0
Points 2 and 3 are perfect IMO:

• Ability to choose models, say from detection people can choose retinanet, SSD, etc.
• HuggingFace intergration! How nice to transparently fine tune HF models (Maybe choose a task and then a model), an awesome starter for many NLP applications.