The following package

http://packagist.org/packages/midgard/createphp

is not auto-updated since 2012-07-26 13:57 UTC

If I look into the github admin settings, everything looks good, and when I click "Test hook" it tells me that the payload is deployed. Could it be that something doesn't work right on the packagist side of things? In my other repos, I have the same configuration and they work fine, it's just this one that gives problems

Filing a separate issue following from #470, given this is not related to SlowTimer.

This still happens on a regular basis in Wikimedia CI pipeline. Is there a way in which we can prevent this issue in a more general way, that hopefully also avoids too much load or storage pressure on your side?

See https://phabricator.wikimedia.org/P7484$1052 for a recent transcript of a build in which this error occurred.

For that build, it seems like the failure was printed only 4 seconds after the composer require command.

01:00:57  DEBUG:quibble.cmd:composer require composer/spdx-licenses=1.4.0 psy/psysh=0.9.6 monolog/monolog=~1.22.1 phpunit/phpunit=4.8.36 \|\| ^6.5 wikimedia/avro=1.8.0 mediawiki/mediawiki-codesniffer=21.0.0 wmde/hamcrest-html-matchers=^0.1.0 seld/jsonlint=1.7.1 wikimedia/testing-access-wrapper=~1.0 jakub-onderka/php-parallel-lint=0.9.2 jetbrains/phpstorm-stubs=dev-master#38ff1a581b297f7901e961b8c923862ea80c3b96 hamcrest/hamcrest-php=^2.0 nmred/kafka-php=0.1.5 justinrainbow/json-schema=~5.2 nikic/php-parser=3.1.3 cache/integration-tests=0.16.0
--
01:01:00
01:01:00    [Composer\Downloader\TransportException]
01:01:00    The "http://packagist.org/p/provider-latest%2489d14de6aab31e05c38c5a490ca286c3895c7713604e767413aeb3ee5f9d0784.json" file could not be downloaded (HTTP/1.1 404 Not Found)
01:01:00
01:01:00  Exception trace:
01:01:00   () at /srv/composer/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php:430
01:01:00   Composer\Util\RemoteFilesystem->get() at /srv/composer/vendor/composer/composer/src/Composer/Util/RemoteFilesystem.php:101
01:01:00   Composer\Util\RemoteFilesystem->getContents() at 

Also:

• https://github.com/composer/packagist/issues/470
• https://github.com/composer/composer/issues/2198
• https://github.com/composer/composer/issues/2228
• https://github.com/composer/composer/issues/7021
• https://github.com/composer/composer/issues/7404
• https://github.com/composer/composer/issues/7599
• Downstream: https://phabricator.wikimedia.org/T182266

We should allow users to delete new packages (recently created & few installs) so that mistakenly added packages can be removed without danger of projects depending on them already.

Github has officially marked the github services feature as deprecated: https://developer.github.com/changes/2018-04-25-github-services-deprecation/

As of October 2018, it will be impossible to enable it for new repos. As of January 2019, it will stop working for all repos.

The migration needs to be performed before that time.

Hey,

from start I would say that I love the idea of composer + packagist, also I really love FOSS. I use quite often the packagist.org page, and I must say that I have some parts missing, yet some parts I recognize as not best from UI look (I'm not a designer, just simple user =) so not kill me too fast for those words =)), so I decided to give some of my free time to create this proposal, which is kinda prototype, but IMO it's at least a bit more usable =)

Let me give some details below, and decide what to do, I mean, should it be official or not? =)

After some comments from people after showing the sneak peak:

I'm showing my work here, to have comments, disscussion, bashing or whatever :panda_face:

Right now at this PR last version of header is used:

Here is really simple TODO list for pages/macros not redesigned:

• [x] homepage
• [x] edit profile
• [x] change password
• [x] my profile
• [x] list of packages
• [x] search page (results - bases on above)
• [x] my packages (bases on above)
• [x] my favourite packages (bases on above)
• [ ] package page (bases on above)
• [ ] vendor page (bases on above)
• [x] popular packages (bases on above)
• [x] explore (bases on above)
• [x] browse (bases on above)
• [x] show profile
• [x] login
• [x] register
• [x] remind password
• [x] error page
• [x] statistics
• [x] submit package
• [x] about
• [x] feed

Additional TODO list:

• [ ] port javascript to new version
• [ ] clean up images/fonts/css files
• [x] update to Bootstrap 3

I could miss something in that list or duplicate, sorry for that =)

Largely recognized (can't wait for the debates on what that is) organizations should be able to own their namespace, so that nobody can submit a package in it. This just to avoid confusion and potential injection of bad code.

https://packagist.org/packages/jurchiks/numbers2words

When I initially added the package, the composer.json file did not contain version info and there was no version tag, but the command composer require jurchiks/numbers2words did not work and continues to not work: [InvalidArgumentException] Could not find package jurchiks/numbers2words at any version for your minimum-stability (stable). Check the package spelling or your minimum-stability

Since adding the package, I have added a github push hook, pushed a "version": "1.0.0" addition to the repository, upped the version to 1.0.2, added a git tag 1.0.0 and deleted the "version" entry in composer.json file. I've tried deleting the version shown on the package page and manually updating it. Nothing helps! It is still detecting only dev-master.

WTF? What does it want from me?

Dear packagist developers

I believe your website has a bug: when I login into your website, and access my newly published repository: https://packagist.org/packages/vasilevich/currencyconverter the readme is visible just fine:

but when I go into icognito mode in my browser same page I see this:

why the readme is not shown? and if its a feature and not a bug, its very weird you should atleast warn the user that only as a registered user you can see it.

Thanks.

In order to get better package selection, it would be good to sort results based on downloads, number of stars, forks, any other things that promote package maturity.

I live in a country with terrible internet connection and I don't know if this is implemented already on the packagist.org If not then here's my question

does packgist.org has mirror sites so composer can download updates closer to my location? thanks :)

Package names are now required to be lowercase. But, this wasn't always the case and I have a few packages that have uppercase letters. This is causing an interesting problem.

Say I have two packages with the names Masterminds/Fortissimo and masterminds/fortissimo-twig. In the vendor directory two directories for masterminds will be created on linux. One with and one without the capital letter. On mac it will just be one directory named Masterminds. Mac seems to be case insensitive. But, generate a phar file and inside that the classes are case sensitive again.

I thought the solution would be to update Masterminds/Fortissimo to be masterminds/fortissimo and did just that. Unfortunately, when getting the package from packagist the directory is still created as Masterminds/Fortissimo rather than the lowercase version. If I point composer to the git repo directly this is not an issue.

So, there appears to be an issue where Packagist is still keeping the uppercase names. This mixed case is creating a problem.

Upgrading to Symfony 6.2 with following steps:

• [x] Bumping Symfony dependencies to ^6.2
• [x] Bumping Rector to v0.15 and PHPStan to v1.9.2 (to utilize Rector presets)
• [x] Running Rector with SYMFONY_62 preset
• [x] Removing sensio/framework-extra-bundle (all used attributes are now part of Symfony core)
• [x] Removing deprecated security.enable_authenticator_manager config
• [x] Refactoring ArgumentValueResolvers into ValueResolvers
• [x] [Minor] Running CS Fixer
• [x] [Minor] Bump phpstan-doctrine and php-symfony

See https://github.com/symfony/symfony/blob/6.2/UPGRADE-6.2.md and https://github.com/rectorphp/rector-symfony/blob/main/config/sets/symfony/symfony62.php

Background

I am currently developing a tool that aggregates versions of packages used in an agencies projects. As such, I am using the composer v2 API to periodically look for new versions. This works fine, but having the README in the tool would be nice - that way potential changes in the package could be seen directly when viewing a potential package upgrade in my tool.

Unfortunately, the v2 API does not seem to provide information about the README - however, the following API-path to READMEs does seem to exist:

• The v1 API exposes a uid for each version
• This uid can be used in the /versions/{uid}.json endpoint

There are 2 problems with this, though:

1. The v1 API is deprecated
2. The versions API does not seem to be meant for public consumption

Proposed Solution I propose the following changes, which should make it easier to fetch the READMEs without introducing big changes:

• Add the uid property to the v2 API
• Document the versions API (This also means that the API must be stable in the future, though)

I have not yet looked at the code that provides these APIs, but my understanding is that at least the v2 metadata is stored in static files, which in turn means that changing their schema requires all files to be regenerated, which may produce a lot of overhead just for this small change.

I just tried to add a new package and received a "Gateway error". After reloading (F5) the package was added but an error message appears which seems to have the link unwanted escaped:

As an organization manager, I would like to be able to control who can access my packages so I can give access to new employees and also remove leavers.

At the moment this has to be done package by package, which can get burdensome if your number of packages grows.

Ideally, there should be something like "organizations" where organizations admins can manage users belonging to the org. Similar to what GitHub, NPM, etc.. offer.

This would also be a great way to control vendor namespace ownership. The current approach of "if you are in a single repo, you have access to the whole namespace" is a bit flaky. What if you have an external contributing to a single package?

Something like SSO would be just awesome, but I consider that more of a paid enterprise feature.

Bumps twig/twig from 3.4.2 to 3.4.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.