Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move binaries outside of /tmp by default #413

Closed
Leon0824 opened this issue May 31, 2022 · 8 comments · Fixed by #454
Closed

Move binaries outside of /tmp by default #413

Leon0824 opened this issue May 31, 2022 · 8 comments · Fixed by #454
Labels
Projects

Comments

@Leon0824
Copy link
Contributor

Problem

Currently, the downloaded binaries are placed in /tmp/ on Linux. However, /tmp/ directory is cleared on boot everytime.

Suggested solution

Placing the binaries in /var/tmp/ on Linux. See Temporary folder.

Alternatives

Placing the binaries in site-packages/prisma/

@donny-son
Copy link

Placing binaries in /var/tmp would be great for multiple projects. Also looking forward to this implementation on Macs.

@RobertCraigie
Copy link
Owner

RobertCraigie commented May 31, 2022

The reason they're placed in /var/tmp/ is to avoid unnecessarily bloating user storage with version upgrades as the engine binaries are quite large.

I now understand that the Prisma TypeScript Client stores them in ~/.cache/prisma/ so I'm considering switching the default to match that.

I think the best solution for this is to support configuring the binaries directory through an env variable or an entry in a pyproject.toml file, for example:

[tool.prisma]
binaries_dir = "~/.cache/prisma-binaries"

Apologies for the duplicated comments, my internet connection dropped while I was posting.

@RobertCraigie RobertCraigie added this to To do in v1.0.0 via automation May 31, 2022
@RobertCraigie RobertCraigie changed the title Move the downloaded binaries to /var/tmp instead of /tmp Move binaries outside of /tmp by default May 31, 2022
@iddan
Copy link

iddan commented Jun 5, 2022

This has created issues for me when deploying to Heroku. Heroku's Python build pack doesn't copy the binaries to the production app and so it is left without the binaries. Had to go through various hoops to make it work. Would be great if I could have just sourced the binaries from site_packages or another directory that Heroku copies by default.

@RobertCraigie
Copy link
Owner

Yeah this is something I'd really like to have, in terms of the direct site-packages binaries this would be solved with #55.

A more feasible solution that could be implemented soon would be the environment variable support which would mean that you could set the environment variable to point to your site-packages.

@RobertCraigie
Copy link
Owner

You can now configure the location of the binaries through either a pyproject.toml file:

[tool.prisma]
binary_cache_dir = '.binaries'

Or through an environment variable, e.g.

PRISMA_BINARY_CACHE_DIR=".binaries"

The default location is still in a temporary directory, however I plan on changing that soon.

@max-programming
Copy link

You can now configure the location of the binaries through either a pyproject.toml file:

[tool.prisma]
binary_cache_dir = '.binaries'

Or through an environment variable, e.g.

PRISMA_BINARY_CACHE_DIR=".binaries"

The default location is still in a temporary directory, however I plan on changing that soon.

I tried adding the custom env variable and also using the pyproject.toml file too. But it always downloads in the /tmp folder
image

@RobertCraigie
Copy link
Owner

@max-programming The aforementioned feature has not been released yet. You can try it out by installing from github like so:

pip install -U git+https://github.com/RobertCraigie/prisma-client-py

@max-programming
Copy link

Thanks @RobertCraigie. Had a hard time finding out this exact command.

v1.0.0 automation moved this from To do to Done Dec 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging a pull request may close this issue.

5 participants