You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @rcarmo - since you mentioned bun I thought I'd document an idea I have been thinking about lately and see what you think. I'm not saying this is a direction piku should definitely go in, more of a thought experiment.
Problems I have faced with the current installation-on-deploy setup. Sometimes I want to:
Install both Python deps and node deps.
Use a different package manager than pip/npm.
Install with a non-supported method (e.g. Clojure has multiple competing ways of managing deps).
Quickly support some new runtime (e.g. bun or even more exotic stuff).
A potential solution is a recipe based architecture. We would remove all the auto-detect stuff from the core piku.py script. The user would then add the deployment command either to ENV or Procfile (like they do for the "release" worker now). In the repo there would be a number of recipes for installing with different package managers into $ENV_ROOT. We could update the piku local command to make it super easy to fetch/print these recipes e.g.:
piku release-command node >> Procfile
This would fetch the release command for node, prepend release: and add it to the Procfile.
One thing I like about this approach is it would simplify the piku.py script itself and potentially make it easier for others to contribute.
On backwards compatibility, we could uses a new name for the worker that isn't release (maybe call the worker deploy?) and run it before the other installation detection. If the worker is not defined then it would fall back on the default installation methods (but if it is, it would skip them).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi @rcarmo - since you mentioned
bun
I thought I'd document an idea I have been thinking about lately and see what you think. I'm not saying this is a direction piku should definitely go in, more of a thought experiment.Problems I have faced with the current installation-on-deploy setup. Sometimes I want to:
bun
or even more exotic stuff).A potential solution is a recipe based architecture. We would remove all the auto-detect stuff from the core
piku.py
script. The user would then add the deployment command either toENV
orProcfile
(like they do for the "release" worker now). In the repo there would be a number of recipes for installing with different package managers into$ENV_ROOT
. We could update thepiku
local command to make it super easy to fetch/print these recipes e.g.:This would fetch the release command for
node
, prependrelease:
and add it to the Procfile.One thing I like about this approach is it would simplify the
piku.py
script itself and potentially make it easier for others to contribute.On backwards compatibility, we could uses a new name for the worker that isn't
release
(maybe call the workerdeploy
?) and run it before the other installation detection. If the worker is not defined then it would fall back on the default installation methods (but if it is, it would skip them).Beta Was this translation helpful? Give feedback.
All reactions