Closed bollwyvl closed 5 years ago
That is a whole bunch of jobs. Funny thing is, it shouldn't take any longer than what we were doing before.
🙈👍🚀👌
it looks like we have a viable approach here. it's nice that it isn't taking an appreciable amount of extra time to do 6 additional installers/tests, which validates keeping it all in the same place.
It should be fairly easy to add just about any other custom spins we would want, and of course we'd want to do more testing of the things we ship... no need to test robot, as each of them is already doing that for the most part, but no doubt there are some things worth checking to make sure they are working.
Anyhow, it's not my coal or hard disks, so I'd say we can go ahead and just start doing this, pending any other packages we should be building/including, or any other review.
Just awesome. I'll find a time to give those Windows builds a spin...
Probably needs some documentation later about where to find and how to run the binaries / scripts, but RIDE did run fine on Windows.
Probably needs some documentation later about where to find and how to run the binaries
There are some built-in capabilities for this on windows in conda-build that i can explore... but indeed, we'd need some documentation for each of these.
All those builds, not getting built now! Give me an emoji, and I'll merge.
I also added a buildId
to all of the outputs, for ease of downloading, which seemed convenient. But then it goes and works the first time, so i didn't have to download them and/or clean out any old ones.
I did do some drawing: nothing super solid to show for it. There's not much you can do with a feature table, and there's certainly bounded complexity to how much you can stuff in there. There are a few hierarchies that came to mind, but i think one of the more logical ones was...
man
/libdoc/inspector/lsp/...)rm -rf
vs click-and-uninstall
A funny thing that came to mind, sort of related to the Hub concept, is a "Pro" spin (think a second, full day workshop), which includes the things you would need to extract, build, test, and package new robot libraries (or extensions to kernel) as part/in support of a team. On the backend, you'd have your tooling like git
, while on the front-end, I'd stuff in jupyterlab-git. Ship pytest
, robotframework-statuschecker
, robotframework-lint
, black
, etc. Ship conda-build
, and maybe even constructor
(since we can't ship nix :stuck_out_tongue_winking_eye: ). Anyhow :pizza: for thought.
All this sounds great as usual! I have more time to thing all this starting from November, when I start updating workshop materials. So many possibilities that hard to know where to focus with limited time without much real user feedback :/
Yeah, have been trying to get some folks excited about a local workshop in house... It would be good to get some more feedback!
On Wed, Oct 16, 2019, 23:16 Asko Soukka notifications@github.com wrote:
All this sounds great as usual! I have more time to thing all this starting from November, when I start updating workshop materials. So many possibilities that hard to know where to focus with limited time without much real user feedback :/
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/robots-from-jupyter/robotlab/pull/52?email_source=notifications&email_token=AAALCRERCZ2TVQPXJK6QOBDQO7KKFA5CNFSM4I44YJL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOTNRA#issuecomment-542979780, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALCRFUIY72XQUXEQZGP4LQO7KKFANCNFSM4I44YJLQ .
This starts experimenting with some ideas from #42.