python-discord / quackstack

An on-demand procedural ducky delivery service. An infinite stack of duckies!
MIT License
7 stars 1 forks source link

Put all the necessary quackstack assets into the branding repo. #2

Closed lemonsaurus closed 3 years ago

lemonsaurus commented 3 years ago

In order to procedurally generate ducks, we need duck templates and accessories.

Currently, these are available in https://github.com/python-discord/aaaaAAAA/tree/main/assets/duck-builder, and should be copied over into the branding repo.

We also need to decide on a way to access these resources from within this repo. Two options are:

Akarys42 commented 3 years ago

Submodules sucks, we would have to manually bump it in this repo when branding is updated. API calls could work, what about downloading the zip of the branding repo during build and decompress it?

jb3 commented 3 years ago

Downloading a ZIP during build sounds fine, but maybe a background task in quackstack itself is a better idea? That way we don't have to redeploy every time we want to get new assets in.

I'm not of the opinion that submodules suck, per se, but I think that for a repository that is as active as branding and the want to have new assets live on quackstack immediately it does present a bit of a problem that we need to manually bump here.

Akarys42 commented 3 years ago

Right now we use a submodule. I think it is better to switch it to a zip download though, what do you think?

The idea of a background task is interesting, but I'd still like to inject it into the image to avoid downloading it every time the image is pulled.

jb3 commented 3 years ago

Having to rebuild the whole image when we update assets is not an ideal solution though.

Maybe we should use only API calls to the branding repo for listing directories and cache assets downloaded.

HassanAbouelela commented 3 years ago

I don't think version bumping is such a bad idea to be honest. I get wanting assets to go live immediately, but python-discord/branding#148 demonstrates some of the problems of having a non-locked dependency.

From my understanding of the issue, if that PR was merged right now, and we had automatic pulling of assets, quackstack would crash. I think that expecting two PRs in two different repos for one change is a lot yes, but that's preferable in my opinion to the suggested alternative.

That being said, there is another choice. Bring quackstack assets into this repo.

jb3 commented 3 years ago

Quackstack assets into this repo does sound pretty alright.

Shivansh-007 commented 3 years ago

There was a discussion in #dev-branding, where it was decided that:

vcokltfre commented 3 years ago

As of #25 all assets have been moved into the repo so I'm closing this issue now