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.

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.

Maintainers should be able to delete a package.

Paginate the list of packages on the home page.

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?

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.

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.

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

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.

Shouldn't setRepositoryManager() be also removed here?

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

The Repositories don't need annotations.

• 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.

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.

Maintainers should be able to add other maintainers.

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

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.

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.

Profile page listing packages a user maintains, or authored.

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.

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

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

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).

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.

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.

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

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.

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.

➜ 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.

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

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.

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

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

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.

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

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.

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.

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.

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

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

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?

Maintainers should be able to delete a package.

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.

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.