Always create proxy files for package binaries,
to avoid not working binaries in case the package
was installed from a path repository and is itself linked
If the binary is a PHP script, a global variable is now exposed,
which holds the path to the vendor/autoload.php file.
This variable can the be used in the binaries to include this file
without guessing where the path to the vendor folder might be.
Additionally it is now checked on binary creation whether
the reference binary has a shebang and if not, generates
a much simple proxy code, because the stream wrapper code,
that is required for PHP <8 to omit the shebang from the output,
can be skipped.
Fixes: #10119
Co-authored-by: Jordi Boggiano <j.boggiano@seld.be>
From the Symfony Dev #french slack channel (symfony-devs.slack.com), people look confused regarding the value to use as license for proprietary projects, even though it's written in the documentation.
Because proprietary software is still a massive part of composer's usage, I think it can be interesting to have it as a note, more readable to people.
Extract from the conversation:
> J’étais sur la bonne page, il me manquait deux lignes de scroll pour voir ça -.- On a tous nos petits moments de faiblesse
Which roughly translates to:
> I was looking at the right page, just about two lines above... We all have our weak moments
They only serve to make anyone reading the docs who doesn't find
something as simple or easy as stated feel bad about themselves, they
don't add anything valuable to the docs in these cases.
You can specify a list of funding options each with a type and URL. The
type is used to specify the kind of funding or the platform through
which funding is possible.
A negative list of non-feature-branches names
is already supported - this patch adds a list of
branches names which *will* be considered as
feature branches.
Allows changing the currently hardcoded set of
expected feature branch names, from:
* master|trunk|default|develop
To any set of names or patterns that you desire.
* docs-improve:
Docs: cleanup version branches section
Docs: those/these composer/Composer
Docs: notice => note
Docs: Fix shell sample output
Docs: Add back a second clear note about hardcoded versions in VCS
Docs: HHVM is not called HipHop
Docs: versions plural, and update == rm lock&install
Docs: don't use short forms, it => composer
Docs: composer.lock lists versions, not constraints
Docs: superfluous comma & it => Composer
The confusing part is probably rather constraints and how versions work, not what they are
Docs: Clarify what "It" stands for
Finished reworking docs to clarify points about versioning (fixes#6088)
Updated basic usage and versions pages to clarify how versioning and package resolution works (refs #6088)
Added some useful overview information about repositories in the Basic Usage documentation.
gnito-org