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

Add Phar file #61

Closed
ad3n opened this issue Nov 17, 2015 · 18 comments
Closed

Add Phar file #61

ad3n opened this issue Nov 17, 2015 · 18 comments

Comments

@ad3n
Copy link

ad3n commented Nov 17, 2015

Add phar file for simplicity

@veewee
Copy link
Contributor

veewee commented Nov 17, 2015

We discussed the phar file in issue #42.
It seems easier to use composer to install GrumPHP in your project or globally.
At the time, we didn't find any usefull reason to create a phar file.

We would love to hear your arguments on why we should add a phar file.
Thanks!

@ad3n
Copy link
Author

ad3n commented Nov 19, 2015

vinkla/climb#28

May be, that is the reason why you need to create a phar file instead of global composer package

@veewee
Copy link
Contributor

veewee commented Nov 19, 2015

@ihsanudin Just discussed the topic with @aderuwe: That is indeed a valid point.
We are currently working on some other improvements which we think will make it easier for developers to extend the application. This means we won't put our time in this phar feature at this moment.

If you want to speed up this feature, feel free to create a PR. Maybe @igormukhingmailcom has the time to help out?

@adam-paterson
Copy link
Contributor

I've been looking into this one this morning, we need to clean up a couple of bits before we can use Box to generate a phar for us.

Found Issues:

  • Autoload redeclare error due to autoload loop in bin/grumphp
  • File "phar:///Users/adampaterson/Code/grumphp/bin/grumphp.phar/src/GrumPHP/Console/Helper/../../../../" doesn't exists.

@veewee
Copy link
Contributor

veewee commented Dec 16, 2015

We should also keep security in mind:
https://mwop.net/blog/2015-12-14-secure-phar-automation.html

@maxime-pasquier
Copy link

Hi,

A Phar file is a must have for your project! Think about composer, we use it because it's simple to get it everywhere.

With the current project, I failed trying to create a Phar file, because of the many hardcoded absolute/relative paths.

@veewee
Copy link
Contributor

veewee commented Dec 20, 2016

Hi @Kmelia,

We did also bump into the same issues as you trying to create a phar. I don't thinkt his will be easy and we'll need to rewrite some code for this feature. We already support many use-cases: local, global, CI, ... and need to make sure that all these cases still work.
Another problem is that GrumPHP is actually a composer plugin, which makes it a bit strange to create a standalone phar.
One last problem is that the dependencies could be local, global or in a bin folder. This makes it hard to make sure that everybody is running e.g. the tests against the same version of phpunit.
I'm starting to think that this feature will cause a lot of work / possible bugs for little gain.

@gnovaro
Copy link

gnovaro commented Jan 31, 2017

@m1guelpf
Copy link
Contributor

Updates?

@veewee
Copy link
Contributor

veewee commented May 31, 2017

No. There are some issues with the different type of paths which need to be solved before we can create a phar file. The idea is to make every path relative to the config file. This is hard to get right since we are supporting a lot of different installation types, project structures, OS, ... already. Currently I don't have the time to rework that part of the application, so unless somebody else picks it up, I don't think phar support will be launched any time soon.

@paslandau
Copy link

@marabesi
Copy link

would it be a good idea to release a phar that supports only one os and then rolling out updates with more os's?

@drupol
Copy link
Contributor

drupol commented Aug 20, 2019

I'm also willing to have a Grumphp PHAR available. I'm looking into it, but I run into the same issue as @adam-paterson .

@veewee
Copy link
Contributor

veewee commented Aug 22, 2019

I am finishing up working on the paths. See #644.
This would make it possible to generate phars.
Poc: veewee@7c1818f

There are some issues:

  • it now requires all dev dependencies to be included
  • the phpparser task seems to fail for some reason.

I guess it's also better not to include the phar generation code in the repo. But instead use a compiler / shim package as phpstan does:

This will give us the benifit that we don't have to worry about dependencies in this project to much and we can upgrade these more easily.
(The suggested way should be to use the shim package in frameworks like magento, drupal, ...)

@veewee veewee mentioned this issue Aug 22, 2019
11 tasks
@drupol
Copy link
Contributor

drupol commented Aug 22, 2019

Oh great !

What's the issue with the PathHelper ?

And yes, it would be very nice to use grumphp shim indeed :-)

@veewee
Copy link
Contributor

veewee commented Aug 22, 2019

The paths helper is way to opinionated about your project strcture and is pretty much a legacy of the first grumphp version. As you can see in the issues section, there are a lot of paths related issues. Most of them are solved in the new system. Not completely there yet though :)

@drupol
Copy link
Contributor

drupol commented Aug 22, 2019

Good luck mate :-)

@veewee
Copy link
Contributor

veewee commented Aug 30, 2019

I've created a shim package based on the PR above.
Lets move the discussion in there:

https://github.com/phpro/grumphp-shim

Feel free to test it out and to improve it. The composer plugin doesn't work yet and needs to be revisited, but that phar should be useable. ("On my system" anyways :) )

@veewee veewee closed this as completed Aug 30, 2019
@veewee veewee added the Paths Issues related to paths label Aug 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants