The user should be able to solely work with Go tools:
go get github.com/prisma/photongo
A specific version gets locked with the Go modules lockfile:
# go.mod
module github.com/prisma/photongo
go 1.13
require (
github.com/prisma/photongo v0.0.1
)
There will be a fixed, hardcoded Prisma CLI version string in any given commit in the photongo
repository, e.g.
const PRISMA_VERSION = "2.0.4-preview.1"
This pins the PRISMA_VERSION. Photon Go needs to be adapted so that you can invoke the generator by running
go run github.com/prisma/photongo
which downloads the Prisma binaries for you (where? somewhere global? likely in the local directory though, maybe a bin/ folder?). The Prisma binary then handles downloading the requested engines, which versions are pinned by the Prisma CLI (also need to be put somewhere; right now they live in the root project dir).
TODO
- actually publish the Prisma CLI as binaries
- allow passing full commands to the Prisma
provider
, so we can rungo run github.com/prisma/photongo/whatever
- (this project: differentiate between the executable for the Prisma generator (
prisma2 generate
/provide in schema.prisma) and the runnable command for the end-user (go run xxx
)) - How can the user use the CLI for running migrations? Should they additionally install the CLI, or should they use the locally installed binary? How can we make this easier?
Notes
- We should document or make it easy to find out the pinned Prisma CLI version, so the user can keep their Prisma CLI for local dev in sync