composer / packagist

Package Repository Website - try https://packagist.com if you need your own -

Packagist

Package Repository Website for Composer, see the about page on packagist.org for more.

This project is not meant for re-use.

It is open source to make it easy to contribute. We provide no support if you want to run your own, and will do breaking changes without notice.

Check out Private Packagist if you want to host your own packages.

Development

These steps are provided for development purposes only.

Requirements

• PHP for the web app
• NPM (or Docker) for the frontend build
• Symfony CLI to run the web server
• MySQL (or Docker) for the main data store
• Redis (or Docker) for some functionality (favorites, download statistics)
• git / svn / hg depending on which repositories you want to support

Installation

1. Clone the repository
2. Install dependencies:

   composer install
   npm install

3. Start the web server:

   symfony serve -d

4. Start MySQL & Redis:

   docker compose up -d # or somehow run MySQL & Redis on localhost without Docker

   This mounts the current working directory into the node container and runs npm install and npm run build automatically.
5. Create 2 databases:
   • packagist - for the web app
   • packagist_test - for running the tests

   bin/console doctrine:database:create
   bin/console doctrine:database:create --env=test

6. Setup the database schema:

   bin/console doctrine:schema:create

7. Run a CRON job bin/console packagist:run-workers to make sure packages update.
8. Run npm run build or npm run dev to build (or build&watch) css/js files. When using Docker run docker compose run node npm run dev to watch css/js files.

You should now be able to access the site, create a user, etc.

Fixtures

You can get test data by running the fixtures:

bin/console doctrine:fixtures:load

This will create 100 packages from packagist.org, update them from GitHub, populate them with fake download stats, and assign a user named dev (with password: dev) as their maintainer.

Search

To use the search in your local development environment, setup an Algolia Account and configure following keys in your .env.local:

ALGOLIA_APP_ID=
ALGOLIA_ADMIN_KEY=
ALGOLIA_SEARCH_KEY=
ALGOLIA_INDEX_NAME=

To setup the search index, run:

bin/console algolia:configure
bin/console packagist:index

packagist's Issues

Search packages

When the package list becomes very large it will be unfeasible to browse through packages to find the one you are looking for. Should instead put a search box above the package list.

Delete package.

Maintainers should be able to delete a package.

packagist:update not working

➜ packagist git:(fetch-packages) ✗ app/console packagist:update
PHP Fatal error: Call to undefined method Composer\Repository\VcsRepository::setRepositoryManager() in /home/andrew/Work/packagist/src/Packagist/WebBundle/Command/UpdatePackagesCommand.php on line 112

Vanilla master pull, tried to re-update and re-install vendors, one single package (symfony/symfony) added.

Allow dots in package names

Discussion about version suffixes

IMHO any alphanumeric sufix should be recognized as part of package version.

For example I will use X.Y.Z-MN where NM is a code that indicate the symfony branch used for reference. I think that is usefull if in the future I will release parallel versions for SF 2.0 y SF 2.1 maintaining similar features.

Also could be used to show PC architecture or any other data. For example i386, nginx, apache, windows, unix, etc.

Detect package name from repository URL.

When adding a new package, you must enter a "Unique Package Name". However, if this name does not match the package name in the composer.json file, the form returns an error stating what the name should be. Changing the package name to what the form says the package name should be fixes the problem.

This is quite redundant; why not just have the repository URL as the only field, and then detect the unique package name from that?

Add post-receive hook on packagist side

Needs a token per user on our side + a github service hook /cc @grahamc

Delete package.

Maintainers should be able to delete a package.

Issue #69, continued

Shouldn't setRepositoryManager() be also removed here?

https://github.com/andrewtch/packagist/blob/fetch-packages/src/Packagist/WebBundle/Entity/Package.php#L291-295

Import packages from git/svn/..

The current form to add packages and specify everything was good for testing, and it still will be useful to add packages that don't have a composer.json file, but we need automatic import from git repos and such.

Whoever does that can use https://github.com/Seldaek/monolog/ as an example. It contains a valid composer.json file.

Detail page for packages

Should include the different versions, requirements, authors, ...

Though it's not extremely pretty, the data structure is similar to npmjs's detail page, so it can be used as inspiration.

Versions vanish when github dies

The packagist:update --force command will first delete all versions and then try to re-fetch them from VCS. The problem is, when that fails, the versions are simply gone.

Would probably be smarter to first fetch the new versions, then delete the old ones, then store the new ones.

Question on packagist.

What if I wanted to add a third party library to packagist, but the composer.json file was missing. Since it wouldn't be my library, what would I do?

displaying links to dependencies

it would be great if the list of dependencies of a project were displayed as link to their packagist page instead of just a name

[Website] Add pkg:update as cron.

From what I can tell now, it's not being run as a cron because there are many packages that have been waiting for days to be crawled.

Show list of all packages of a vendor on /packages/vendor/

Build dist packages for non-GitHub/BitBucket repositories

Better Integration with Github

It would be nice to be able to login via your Github account.

If you have logged in via Github, it would also be nice to have a way to just mark the repositories that you would like to add to packagist instead of having to specify the URL for each one.

User profile

Profile page listing packages a user maintains, or authored.

Add other maintainers.

Maintainers should be able to add other maintainers.

Support renaming packages

The procedure for renaming packages should be as such:
- Update your composer.json with "name": "new/name" and "replace": {"old/name": "self.version"}
- Press a button on Packagist if you're maintainer, and it will rename if those two preconditions are met.

EDIT: Current solution/procedure:

If you just want to update the github/repo URL

• Do the rename on github or wherever
• Edit the package URL on packagist, no need to change the package name for this

If you really really want to rename a package

• Update the name in composer.json on the master branch or whatever the default branch is
• Resubmit the package to packagist using the new name
• Mark the old package as "Abandoned" on packagist, and use the new name in the form so that people get pointed to it when they install with the old name
• And no you can't keep your download stats

Allow maintainers to mark a release as broken

Broken releases would not appear in the packages.json file anymore.
Broken releases need to be tracked in a separate table, so if the package_version table is erased and versions are refreshed from github the bad ones can be marked as broken again.

Redirect to search if package is not found on packages/foo/bar

Add RepositoryPass to get tagged services.

We should get tagged services instead of hardcoding them in the config.

Packagist repository annotations incorrect.

The Repositories don't need annotations.

Can't log in to Packagist with created credentials

...and when I try the password reset, no email is sent to me (reaches me)!

Admin tasks

• Ability to manage maintainers of a package
• Ability to mark versions as broken (#59)

Those should be displayed inline (not in a separate admin backend) to users that have the proper rights to use them.

Delete or resubmit the repo

Hi @Seldaek ,

What about giving the maintainer to clear it , when added the wrong path ?

For eg : the Aura Router ( https://github.com/auraphp/Aura.Router/ ) was having a json and the name was wrongly pointing to
https://github.com/auraphp/Aura.Signal/ .

What about giving the user an option to remove or resubmit ?

Thanks

Hari K T

Add a json api for packages

being able to query the package informations (without having to get the whole packagist content) would be handy to integrate it with other websites.

Refactor UpdatePackagesCommand into composer

There is lots of special branch handling in UpdatePackagesCommand right now. Since composer will need to do the same, it would be great if it could be handled by composer. Then packagist could just re-use that code.

Clean up FOSUserBundle stuff

Translations are missing, some CSS, not vital but would be nice.

GitHub SHA-1 checksum requires instant packagist update

I just tried to install twig through composer. It gave me a:

[UnexpectedValueException]
The checksum verification of the archive failed (downloaded from https://github.com/fabpot/Twig/zipball/master)

That's because fabien changed something 22 minutes ago, and composer hasn't updated yet. This is really not acceptable. We either need to make composer/packagist more fault tolerant or make sure packagist insta-updates (github commit hooks).

Side note: The locking mechanism to be implemented in composer may help a bit, as you can just lock to that particular commit SHA.

But the point is, we need to solve this checksum per (especially changing dev-) version problem.

Add a page with the list of the repo I maintain

Warn user about uppercase package names

We already have 3 packages on packagist.org with uppercase package names. The naming convention really is lowercase with dashes, ideally we'd warn the user when submitting a package. Possibly even deny package names with uppercase chars.

Full page caching on packages.json

It is likely that when the packagist repository grows large (as it hopefully will), the packages.json will be resource-intensive to generate. To avoid unnecessary usage of CPU, we should cache that packages.json file with full page http caching. A reasonable time would be like 5-10 minutes or so, people don't need packages available right away.

Support importing non-github git repositories

List packages by tag

Users

Would be nice to have users, because packages need owners. They're the only ones that can modify packages, and are the equivalent of maintainers. Maintainers can add/remove other maintainers to their packages.

Crawl package when adding for the first time

It would be nicer for user experience if a package were crawled right when it is added.

Pagination

Paginate the list of packages on the home page.

Add a delay for package version pruning

Some versions disappear sometimes, one possible cause being that if a fetch from GitHub fails, the version won't exist in the VcsRepo, and then the update command will delete it (if it's a -dev one).

Support for Mercurial and Bitbucket

Hello, I have a personal preference for Mercurial over Git (please, let's not make the discussion about this). It would be awesome to be able to hook packagist up to my existing Bitbucket mercurial repositories, or to Mercurial repositories on my own server - I would prefer not to have to move everything to github.

AJAX search yielding a 500 error with some queries

I happened to copy the URL https://github.com/jmikola/JmikolaInsecu into the search box on http://packagist.org/ and an AJAX request was sent off that returned a 500 error.

Unify /profile and /user/{username} sections.

Clicking on the /profile link should redirect to the /user/{username} link, and the user should be able to see additional information on that page.

avoid relative paths

You ought to avoid using relative paths, especially in the autoloader, where they need to be evaluated at run-time, once for every auto-loaded class.

For example, if the following statement was used:

require __DIR__.'/../path/to/file.php';

Let's say this expands to:

require '/path/to/app/folder/../path/to/file.php';

The path "folder" isn't meaningless - it works like an assertion to check that "folder" exists, every time it's executed. But you don't need that feature in the case of an autoloader. Instead, just calculate the base path in advance:

require dirname(__DIR__).'/path/to/file.php';

Which would expand to:

require '/path/to/app/path/to/file.php';

Of course, this doesn't matter for a single explicit require-statement as shown in this example - but it does make a difference in something like an autoloader.

It also makes for more human-readable error-messages when a require-statement fails.

Support for post-receive URLS

If I use packagist for dependency management between my own packages, I need to wait up to an hour for a new version to become available.

If packagist can integrate with github's post-receive URL, or even just have an 'update now' button, this would go a lot faster.

Missing deps file

The deps file used by the bin/vendors script is missing.

Import packages from PEAR

Importing packages from PEAR packages could be useful since they already contain most if not all of the metadata that we need. @beberlei already started working on this.

wrong url for branches version

Currently, the versions for branches reference the commit pointed by the branch during the latest packagist crawling. I think it should use the branch name instead so that someone getting the package can really get the master branch when asking for master-dev

Add Doctrine fixture file

It would be easier to attract contributors to the project if Packagist had a fixture file that would load some packages, authors, etc.

I could have a go at doing it myself but I'm not comfortable enough with the codebase yet.