-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#41 Avoid issues when the package is scheduled for removal #46
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, seems good. I would suggest simulating a removal via the composer
CLI in .travis.ci
(additional step)
|
||
class NotInstalledException extends \RuntimeException | ||
{ | ||
const MESSAGE = "Folder of ocramius/package-versions not found, it seems that it's not installed"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move to a static named constructor instead
src/PackageVersions/Installer.php
Outdated
$composer->getConfig(), | ||
$composer->getPackage() | ||
); | ||
} catch (NotInstalledException $exception) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you are using private-only API, throwing and catching in the same scope seems like a bad idea (it's basically a GOTO implemented via exceptions).
Can this be re-designed somehow?
I've addressed your concerns in two different commits, so it should be easy to review:
[EDIT] Crap, broken build, working on it! |
Ok now build is green! @Ocramius if it's 👍 for you, it's ready to be merged! For some unknown reason tests were failing due to the presence of the new composer.json for the integration test. I preferred switching to a new E2E test for this scenario, it works well too. |
@Jean85 merged, thanks! 👍 |
You're welcome! 😉 |
@ondrejmirtes this was just released: https://github.com/Ocramius/PackageVersions/releases/tag/1.1.3 |
Good, now @Jean85 should require this version in |
Good, now @Jean85 should require this version in |
@ondrejmirtes given that |
@Ocramius I could add a constraint for your package so that it’s resolved
to a correct version but I’d prefer if there was a correct version of
jean85/pretty-package-versions
so that t works without me caring about indirect dependencies.
On Wed, 6 Sep 2017 at 17:33, Marco Pivetta ***@***.***> wrote:
@ondrejmirtes <https://github.com/ondrejmirtes> given that
jean85/pretty-package-versions works as-is, does @Jean85
<https://github.com/jean85> really need to make a release? Even with
preferred stable dependencies, the last patch version should be allowed.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGZuJtxGb3Sj8poAuLa6srDc_-zxl9Mks5sfrtHgaJpZM4PLvxR>
.
--
Ondřej Mirtes
|
No biggies, I can release a patch version too. Doing it right now... |
Makes sense, although you really should always have latest/greatest :D |
This is to solve #41, as proposed in my comment.