composer / packagist Goto Github PK
View Code? Open in Web Editor NEWPackage Repository Website - try https://packagist.com if you need your own -
Home Page: https://packagist.org/
License: MIT License
Package Repository Website - try https://packagist.com if you need your own -
Home Page: https://packagist.org/
License: MIT License
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.
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.
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.
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.
โ 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.
The deps file used by the bin/vendors
script is missing.
Profile page listing packages a user maintains, or authored.
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?
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.
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.
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.
Those should be displayed inline (not in a separate admin backend) to users that have the proper rights to use them.
Maintainers should be able to add other maintainers.
Needs a token per user on our side + a github service hook /cc @grahamc
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 nicer for user experience if a package were crawled right when it is added.
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.
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.
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
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
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.
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 should get tagged services instead of hardcoding them in the config.
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.
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.
The Repositories don't need annotations.
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.
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.
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.
Maintainers should be able to delete a package.
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.
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.
...and when I try the password reset, no email is sent to me (reaches me)!
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
Translations are missing, some CSS, not vital but would be nice.
Shouldn't setRepositoryManager() be also removed here?
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.
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?
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.
Maintainers should be able to delete a package.
Paginate the list of packages on the home page.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.