diff --git a/Resources/public/img/docs/features/License-Review-20200723.png b/Resources/public/img/docs/features/License-Review-20200723.png deleted file mode 100644 index f06002a3..00000000 Binary files a/Resources/public/img/docs/features/License-Review-20200723.png and /dev/null differ diff --git a/Resources/public/img/docs/features/Packagist.org-Mirror-20230908.png b/Resources/public/img/docs/features/Packagist.org-Mirror-20230908.png deleted file mode 100644 index df97a4e8..00000000 Binary files a/Resources/public/img/docs/features/Packagist.org-Mirror-20230908.png and /dev/null differ diff --git a/Resources/public/img/docs/features/Packagist.org-Mirror-Edit-20230908.png b/Resources/public/img/docs/features/Packagist.org-Mirror-Edit-20230908.png deleted file mode 100644 index 2e36caec..00000000 Binary files a/Resources/public/img/docs/features/Packagist.org-Mirror-Edit-20230908.png and /dev/null differ diff --git a/features/license-review.md b/features/license-review.md deleted file mode 100644 index a1b1c65a..00000000 --- a/features/license-review.md +++ /dev/null @@ -1,24 +0,0 @@ -# Dependency License Review -## - -License Review helps you understand and manage legal challenges with your dependencies. - -You can find your Dependency License Review in your organization's "Packages" tab. You will find a list of all licenses used in any of your packages. License Review allows you to inspect which versions of which dependency are available under which license. Links to details on the respective open-source licenses help you find legal information regarding the licenses. - -![License Review](/Resources/public/img/docs/features/License-Review-20200723.png#no-spacing) -Dependency License Review for the "ACME Company" organization on Private Packagist - -## Open-Source Licenses -Open-source licenses come in a **lot of flavours** like weak and strong **copyleft** or **permissive** software licenses. In addition to the **great benefit** of being able to reuse code, open-source licenses present **some challenges for businesses**. With a complex project making use of open-source frameworks and libraries you will have to determine which open-source licenses allow you to incorporate which work into your own. This depends on the type of product you are building, whether you are providing a service or shipping code to customers, and the license you pick yourself. - -The **[Open Source Initiative](https://opensource.org)** is a great resource to learn more about open-source licenses. They have implemented a review process for open-source licenses so it becomes easier to determine whether a given software license is an open-source license at all. - -## SPDX: Standardized Open-Source License identifiers -The **[Software Package Data Exchange (SPDX)](https://spdx.org)** curates a list of license identifiers that enable automation around licenses in complex systems made up of large numbers of components. Composer makes use of this list with its composer/spdx-licenses library. Composer warns you if the license in your composer.json “license” key cannot be identified using this library. **If you maintain any open-source package, please review your composer.json and ensure that you are using a valid SPDX license identifier** to help your users manage their dependencies. - -Based on the SPDX identifiers Private Packagist License Review provides a list of all open-source licenses used by packages in your package repository. You can browse packages by license, and see if the licenses for a package changed over time. - -If you know of or find packages using Private Packagist License Review, which do not use an SPDX identifier, please get in touch with the maintainers or simply send them a pull-request. Often it’s simply a matter of slightly modifying the identifier. By the way, if your package is **dual licensed**, please specify an **array of licenses** in your composer.json instead of hardcoding the word “or” into the string to help automated systems understand your licensing. - -## Private Packagist License Management Roadmap -This is merely the first tool to help you manage the licenses of your dependencies. We’re planning to expand on this functionality by allowing you to define a set of open-source licenses, to allow or reject for new packages, in order to prevent your developers from accidentally requiring packages with an incompatible license. Once we implement notifications, we’ll make you aware of new licenses that you should review when they are first added to your repository. diff --git a/features/mirroring-composer-packages.md b/features/mirroring-composer-packages.md deleted file mode 100644 index a41da830..00000000 --- a/features/mirroring-composer-packages.md +++ /dev/null @@ -1,25 +0,0 @@ -# Mirroring Composer Packages -## Redundancy and Dependency Integrity with Private Packagist - -When you first run Composer, you usually install some open-source dependencies from its default package archive [packagist.org](https://packagist.org). Packagist.org is the public repository for all open-source PHP packages. So when you add an open-source dependency to your project Composer fetches its metadata, its description, a list of versions, requirements, etc., from Packagist.org. - -## Installing packages from Packagist.org -**Packagist.org only collects and serves package metadata.** Most importantly the names of packages, their respective dependencies and the location of their source code. Once Composer resolved the set of dependencies it writes out the _composer.lock_ file containing all metadata for versions of packages that need to be installed. Composer then downloads every package listed in _composer.lock_. For each package **Composer** either **downloads** a **distribution file** (zip or tar) or **clones** the respective **version control system** (git, hg or svn) **defined by the package maintainer**. By default it selects a distribution file for every tagged release, you can modify Composer’s preference with the `--prefer-source` and `--prefer-dist` options. - -This means that **installing open-source packages from Packagist.org relies on the respective package maintainers’ source code hosting to be up and running whenever you run _composer install_**. Most of the time that’s GitHub but it may be any other service or even hosted by the package maintainer themselves. Packagist.org doesn’t handle building archives, storing or distributing the package source code. - -## Removing the single point of failure for installs -When using Composer with **Private Packagist, Composer will store two download locations** for every package in your composer.lock: the Private Packagist mirror URL and the original download URL. Composer will download the Private Packagist mirror of distribution files which gives you **faster downloads**. But more importantly **even if GitHub, Bitbucket, GitLab or an open-source maintainers self-hosted version control system are down, _composer install_ can still install your dependencies!** So if you rely on _composer install_ in your build process it no longer depends on these services being available. But better yet, since Composer stores both URLs this **protects you from any Private Packagist downtime too!** There is **no longer any single point of failure**. - -Further, mirroring gives you a copy of all dependencies your production system requires, so even **if an open-source maintainer deletes their project** you can safely switch to a new package at your own pace, because **Composer can still install it** from your Private Packagist repository until you remove it, too. - -## Mirrored Repositories on Private Packagist -When you create a new organization on Private Packagist, it is **automatically set up to mirror** all your dependencies from the open-source package archive **Packagist.org**. But you can mirror any number of public or private repositories, e.g. the Drupal package repository or Magento Marketplace (see “[Mirroring Magento Marketplace Packages](./../docs/mirror-magento-marketplace.md)”). - -![Packagist.org Mirroring](/Resources/public/img/docs/features/Packagist.org-Mirror-20230908.png) - -By default packages are automatically mirrored and added to your Private Packagist repository the first time they are accessed through composer update. Automated systems using Private Packagist access tokens cannot mirror new packages to ensure that build processes do not have unintended consequences. - -![Packagist.org Mirroring](/Resources/public/img/docs/features/Packagist.org-Mirror-Edit-20230908.png) - -You can configure the mirroring policy on a per-repository basis. For example you can ensure new open-source dependencies are discussed or reviewed before they are manually added by an administrator, making them available to all developers in the organization. diff --git a/features/private-vcs-packages.md b/features/private-vcs-packages.md deleted file mode 100644 index 9d1757fd..00000000 --- a/features/private-vcs-packages.md +++ /dev/null @@ -1,58 +0,0 @@ -# Private Composer Packages -## - -Private Packagist makes the code in your private repositories available for use with Composer. - -## Where can Private Packagist get code from? -Private Packagist can access private code in any Git, Mercurial or Subversion repository with SSH or HTTP Basic authentication. This includes code stored on any of the following systems: -* GitHub -* GitHub Enterprise -* GitLab.com -* GitLab Self-Managed -* Bitbucket.org / Cloud -* Bitbucket Data Center / Server - -## How does the setup in Private Packagist work? -First configure a set of credentials for the service you are using to store private code. Then add any number of packages by entering the respective repository URLs. Private Packagist will download your code, inspect all composer.json metadata and make the packages with all their versions available for browsing in your account. - -If you are using our GitHub synchronization we will list all your repositories automatically, and you can pick which ones to add with a single click. - -## How do I use Private Packagist in Composer? -Add the Private Packagist repository to your composer.json and require the packages by name as you are used to. If you already had private version control system repositories configured, you can remove them to speed up composer update. - -
-
-{
-    "repositories": [
-        {"type": "vcs", "url": "https://github.com/your-org-name/foo"},
-        {"type": "git", "url": "https://github.com/your-org-name/bar.git"},
-        {"type": "composer", "url": "https://repo.packagist.com/your-org-name/"},
-        {"packagist.org": false}
-    ],
-    "require": {
-        "org/foo": "^1.2.3",
-        "org/bar": "dev-master"
-    }
-}
-
-
-**Note:** Your composer.lock file contains the download URLs for packages. You need to run composer update at least once to regenerate your composer.lock file before composer install will download files from Private Packagist. - -## How do I configure a VCS repository with multiple composer.json files? - -Private Packagist supports multiple packages per VCS repository, but you'll need to specify where the `composer.json` files are located. - -When adding a new package, select the option _Repository contains multiple packages or composer.json is located in a subdirectory_. You can either specify the path to the `composer.json` file directly (if you have a single package in a subdirectory), or use a glob pattern such as `{lib,src}/**/composer.json` to specify multiple locations. - -### Globbing - -- `?` matches any character -- `*` matches zero or more characters, except `/` -- `/**/` matches zero or more directory names -- `[abc]` matches a single character `a`, `b` or `c` -- `[a-c]` matches a single character `a`, `b` or `c` -- `[^abc]` matches any character but `a`, `b` or `c` -- `[^a-c]` matches any character but `a`, `b` or `c` -- `{ab,cd}` matches `ab` or `cd` - -A glob pattern of `**/**` will find all `composer.json` files in the repository.