Closed jlmitch5 closed 4 years ago
Gonna get going on this as described above and see what I can figure out, let me know if there are any concerns with the approach outlined!
happy new year!
these suggestions are good--- any help on them would be hugely welcome.
I might be able to help, but have a lot of stuff going on so I can't make any promises.
if I could get the deps to work that would help, but it seems we changed from using glide to using go modules, which does not work in the old clone, nor does it work in a place not in the gopath (clone in ~/maiden)
I get
new_maiden ➤ go install git:master*
../.go/src/github.com/gin-gonic/gin/binding/default_validator.go:11:2: cannot find package "github.com/go-playground/validator/v10" in any of:
/usr/local/opt/go/libexec/src/github.com/go-playground/validator/v10 (from $GOROOT)
/Users/jmitchell/.go/src/github.com/go-playground/validator/v10 (from $GOPATH)
../.go/src/github.com/coreos/go-systemd/dbus/dbus.go:26:2: cannot find package "github.com/godbus/dbus/v5" in any of:
/usr/local/opt/go/libexec/src/github.com/godbus/dbus/v5 (from $GOROOT)
/Users/jmitchell/.go/src/github.com/godbus/dbus/v5 (from $GOPATH)
@tehn @ngwese @pq
I see now that I might need to update go as that was bumped to, trying that
works now, wish I would have realized that sooner...went on a very long goose chase trying to figure out what the problem was hah
alright dev environment all set up, hopefully the changes aren't too difficult and I can get this in when I get another evening of time
Sorry about the confusion around the glide
to go modules switch. I just checked the README and I did update it to mention go 1.12+ but obviously that doesn't help if you already had the repo cloned!
...would very much welcome the above improvements.
@ngwese No problem.
it doesn't look like I get any "available packages" when setting up my local maiden env as described here
https://github.com/monome/maiden/tree/master/web#typical-workflow
"installed packages" tab does work (and update works), so I should be able to tackle that part of my suggestions.
The instructions are probably stale. One wrinkle which isn't documented is that the maiden
repo now has norns-community
registered as a submodule. The default config(s) for where to pull packages are in that repo.
git submodule update --init
should get you the extra files in your local dev environment. You'd then need to copy this directory https://github.com/monome/norns-community/tree/master/sources to which ever data dir you are pointing the maiden
daemon at.
thanks @ngwese, didn't realize that, have got the submodules now and have cp'd the sources dir.
No dice on getting any thing in availabel (api/v1/catalogs is returning catalogs: [])
In the go console, it looks like it is trying to look at
/users/jmitchell/dust rather than /users/jlmitchell/norns/dust (though you can seem some are looking in the right place it seems
my maiden command is ./maiden server --app web/build/ --data ~/norns/dust --doc ~/norns/norns/doc --debug
I fixed it @ngwese. I added /norns after $HOME to all the places in maiden.yaml and restarted my ./maiden terminal
# catalog source config file paths; can be glob patterns
sources:
- $HOME/norns/dust/data/sources/*.json
# output dir for catalogs generated from a source
catalogOutputDir: $HOME/norns/dust/data/catalogs/
# catalog file paths; can be glob patterns
catalogs:
- $HOME/norns/dust/data/catalogs/*.json
# dust directory details
dust:
path: $HOME/norns/dust/
code: $HOME/norns/dust/code/
thanks for your help figuring this out. now I for sure have the dev environment all set up to tackle this
You can also specify which config file you want maiden to use via a command line flag. IIRC have a modified "maiden-dev.yaml" config file which has the paths moved around to work when I'm running things on my laptop.
👍 sweet
as we were discussing in https://llllllll.co/t/norns-update-191028-maiden-1-0/26614/22 wanted to create an issue for enhancements to the package install/update ui. Namely:
I think this one should be easy and only need front-end work, because we already are grabbing the list of installed packages for the installed tab.
After discussion it seems clear that we don't want to get in the business of handling git diffing and being a git client with maiden, so I'm trying to think of this update all function as basically just being a slightly modified ui of the exact update mechanism that happens now...just sort of "scripting" the sequence of actions. Does that sound like an okay path forward?
For this feature, it would be nice if either
a) "update" turns to "updating" for each package in the installed list
or
b) the modal that is displayed after clicking confirmation changes text to show you which package is currently attempting install
so that we may indicate progress as the "update all" action may take a bit to get through and may look like something is stalling/crashed if there isn't progress indication. I don't really have a preference of ux between the two.
It also might be nice to be able to cancel the operation and stop any additional packages from being installed if you want to abandon.
Any errors should be held til after the process is completed or canceled, and then the errors concated in a single error modal at the end.
While knowing if a package has been updated or not would be cool, I can't think of a way to do it without introspecting the git hash of the current head of the default branch and diffing with whatever is local to norns, and I don't think that's something we want to do. I think that "update all" will make knowing up to date status less useful.