{"action":"closed","issue":{"url":"https://api.github.com/repos/ELEKTRONN/elektronn3/issues/4","repository_url":"https://api.github.com/repos/ELEKTRONN/elektronn3","labels_url":"https://api.github.com/repos/ELEKTRONN/elektronn3/issues/4/labels{/name}","comments_url":"https://api.github.com/repos/ELEKTRONN/elektronn3/issues/4/comments","events_url":"https://api.github.com/repos/ELEKTRONN/elektronn3/issues/4/events","html_url":"https://github.com/ELEKTRONN/elektronn3/issues/4","id":309076288,"number":4,"title":"Decide what to do with train.py","user":{"login":"mdraw","id":6719909,"avatar_url":"https://avatars3.githubusercontent.com/u/6719909?v=4","gravatar_id":"","url":"https://api.github.com/users/mdraw","html_url":"https://github.com/mdraw","followers_url":"https://api.github.com/users/mdraw/followers","following_url":"https://api.github.com/users/mdraw/following{/other_user}","gists_url":"https://api.github.com/users/mdraw/gists{/gist_id}","starred_url":"https://api.github.com/users/mdraw/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mdraw/subscriptions","organizations_url":"https://api.github.com/users/mdraw/orgs","repos_url":"https://api.github.com/users/mdraw/repos","events_url":"https://api.github.com/users/mdraw/events{/privacy}","received_events_url":"https://api.github.com/users/mdraw/received_events","type":"User","site_admin":false},"labels":[{"id":883926661,"url":"https://api.github.com/repos/ELEKTRONN/elektronn3/labels/discussion","name":"discussion","color":"4ad651","default":false}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-03-27T18:08:44Z","updated_at":"2018-04-06T20:25:09Z","closed_at":"2018-04-06T20:25:09Z","author_association":"OWNER","body":"The file `scripts/train.py` is currently used as a provisional entry point for quickly testing changes in elektronn3. It supports some configuration via CLI arguments, but there are still many limiting hard-coded values in it, so editing its source code is often necessary. What do we do with it? The following alternatives came to my mind:\r\n1. Keep it as is, with its small set of options, and declare it as a \"template for custom training scripts\".\r\n2. Reduce its options to a bare minimum again and declare it as a minimum training script template. The standard usage scenario of elektronn3 would then be to make a copy of train.py and customize it for your own needs, always running your trainings from your own version of train.py. We could place multiple alternative versions of it in an `examples` directory, making them take the place of ELEKTRONN2's example configs.\r\n3. Go the ELEKTRONN{,2} way and create an \"official\" `elektronn3-train` entry-point that abstracts common training initialization and where all configurable stuff is placed in training config\" `.py` files. (I don't think this can be implemented in a sensible way.)\r\n4. Just keep adding more CLI options.\r\n\r\nIMO alternative 3 and 4 would lead to too much bloat and overengineering eventually, because there are just too many possible configurations that need to be supported. I would go for 2.\r\nAny other suggestions or opinions?"}}
{"actor":{"display_login":"mdraw"}}