My .02 would be to do all of the above. Personally, being able to install Superset via pip was really useful in starting the Superset journey... I would also recommend an official Dockerfile. I'm not sure why you wouldn't want to push it to DockerHub, but if you want to make it easy to adopt I'd push it there as well. Other than the inconvenience factor, I'm not sure why you'd want to limit the venues where people can access Superset.
IMHO, I would say that once versions are approved for release, they should be pushed to Pypi, dockerhub etc. I've never dealt with python projects via Apache, but is the ASF ok with distributing software via Pypi? Just my .02 -- C > On Aug 9, 2019, at 5:44 PM, Maxime Beauchemin <[email protected]> > wrote: > > Hi all, > > How should we go about convenience releases? Currently I'm thinking > Pypi.org, but we could think about Docker / DockerHub as well. > > First thing to know is that a convenience release for Superset is likely to > contain minified [aka "compiled"] javascript out of hundreds of libs. In > theory these libs are scanned and approved by FOSSA license-wise, and > generating that report will be part of the release process. Is that ok? I > mean is Apache ok with us distributing that bundle? > > Alternatively, it could *not* contain the minified javascript. We'd have to > find some solutions to a few challenges. Maybe run a new `superset > build-js` CLI command that would: > * bootstrap `npm` locally > * download JS build deps > * build locally (minutes) > * find a place to put these files (can't mutate Python's install dir > "site-packages") > * ... > > On the docker side, maybe an official Dockerfile, but no official DockerHub > entry? > > Max
