On Thu, Jun 10, 2021 at 4:53 PM François J. wrote:
> Hello,
>
> On Fri, Jun 04, 2021 at 12:50:03AM +0200, Tobias Geerinckx-Rice wrote:
> > Propagated-inputs are a hack that says as much as ‘when the user installs
> > package A, pretend like they also asked to install package B in the same
> > pro
Hello,
On Fri, Jun 04, 2021 at 12:50:03AM +0200, Tobias Geerinckx-Rice wrote:
> Propagated-inputs are a hack that says as much as ‘when the user installs
> package A, pretend like they also asked to install package B in the same
> profile’. That is *not* a good thing! It's a work-around for brok
Phil,
Phil 写道：
As I understand it, as python is not propagated there is no
guarantee that the version of python will be persisted in the
store for
the lifetime of the profile containing (just) the python app?
Inputs are used when *building* things, not to manage their
outputs (artefacts) on
Thanks for the reply.
Tobias Geerinckx-Rice writes:
> If all shebangs and similar entry points have been properly patched,
> why would you need to bundle ‘Python itself to run the app’ at all?
As I understand it, as python is not propagated there is no
guarantee that the version of python will b
Hi Phil,
Phil 写道：
I tend to build manifests containing my python app, and python
itself to run the app. Originally I thought this was necessary
to decouple the
app from a specific version of python, but assuming I'm right
about
the patching of shebangs, this seems to be misguided - as any
en
Hi all,
It seems to be convention not to include python itself as a
propagated-input in python packages?
However the default-python version is included as a native-input for the
python-build-system - this means any shebangs are hardcoded to whatever
the current version of python may be.
Given th
