Skip to content
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

Recommend installing Codeception globally #1238

Closed
samdark opened this issue Jul 23, 2014 · 8 comments

Comments

Projects
None yet
3 participants
@samdark
Copy link
Collaborator

commented Jul 23, 2014

There was a discussion at #1025. I've actually tried it and it works very well. If you have Composer global bin directory in PATH you can call Codeception just as codecept from anywhere. That lowers confusion about quite lengthy commands when running it from vendor. Especially if your apps are deep into subdirectories.

Global installation is recommended for PHPUnit and works very well alongside Codeception.

I think it's safe to recommend such approach in docs instead of current per-project one.

@samdark samdark added the docs label Jul 23, 2014

@samdark

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 23, 2014

@DavertMik what do you think?

@DavertMik

This comment has been minimized.

Copy link
Member

commented Jul 23, 2014

@samdark there was an issue about a week ago, where globally installed Codeception had Guzzle, which conflicted with local one. It was happened because guzzle functions could be required several times, and caused fatal error. This issue was fixed, but I'm not sure, maybe there are other pitfalls we will find...

I don't like the way Composer manages global installation. It does not allow to have multiple versions of packages installed. There might be version conflicts between Codeception, PHPUnit, Guzzle, Symfony Components, etc.

If I only new that globally installed Codeception is isolated from everything else installed globally I would recommend this approach. But currently I don't trust it enough.

@DavertMik DavertMik added the rfc label Jul 23, 2014

@samdark

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 24, 2014

Guzzle fixed the issue. I've tested it and it's not longer a problem.

The issue about version conflicts is still there if you're using phar which is currently recommended so I don't think Composer global install is any different.

@samdark samdark added this to the 2.0.6 milestone Aug 24, 2014

@DavertMik

This comment has been minimized.

Copy link
Member

commented Oct 6, 2014

I think this should go for Codeception 2.1, as it may considered to be a major change.
At least I'm not planning to write some important announcements and docs updates before that

@DavertMik DavertMik modified the milestones: 2.1, 2.0.6 Oct 6, 2014

@zbateson

This comment has been minimized.

Copy link
Member

commented Mar 30, 2015

My one concern with this is it may discourage including codeception as a dependency for an application's "require-dev", which I think is important... especially because it allows each application to define not only the fact that it uses codeception for its testing but also because it allows it to specify what version.

I think recommending that should be the key... so for instance if you're dependent on version 2.0, you should have "codeception/codeception": "~2.0.0". If you rely on a specific feature introduced in 2.0.11 you should use ^2.0.11, etc...

If you end up getting used to calling 'codecept' rather than './bin/codecept' or 'php bin/codecept', you run the risk of running a version of Codecepttion not intended for the application. What are your thoughts?

@DavertMik

This comment has been minimized.

Copy link
Member

commented Apr 21, 2015

I agree to @zbateson points. This may also be important because of 2.1 release
There is also one major issue, which should be taken into account. Codeception installs globally its dependencies which are PHPUnit and Guzzle. And those two can get in conflict with already installed PHPUnit and maybe Guzzle.

Will we take care of issue this decision could produce? I'd like to have global Codeception but there are other points against it:

  • limited autcompletion and code introspection (because library is not bound with project)
  • hard to understand which version of Codeception is really used in project. We do lots of enhancements even in minor releases. It is important to know exactly what version is used.
@zbateson

This comment has been minimized.

Copy link
Member

commented Apr 22, 2015

Yeah, if possible I would recommend installing PHPUnit and Guzzle locally instead of globally. I'm not sure why they were originally configured as global but it makes much more sense to me for them to be local.

Especially when you think how Codeception's PHPUnit dependency (not sure about Guzzle) seems very version-specific but IIRC moves up even in minor releases.

@DavertMik

This comment has been minimized.

Copy link
Member

commented Apr 22, 2015

composer install global is a modern way to say pear install phpunit =)

@DavertMik DavertMik closed this Apr 28, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.