-
-
Notifications
You must be signed in to change notification settings - Fork 202
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Install composer? #4
Comments
Yes, I think that makes sense. As long as it's just composer - and not any global plugins :). We should leave the latter decision to the developer. |
馃檱 馃槈 |
See 5af9e95 |
We also need the asset-plugin, since Yii 2.0 requires it. Otherwise you can't even do: |
IMO either composer or asset plugin should not be in the minimal image. This is not a part of application, just a build tool. When we deploy the app in production, we don't run So, if you aim to create reusable image for both dev and prod, composer is quite an arguable component of it. |
I don't think we really need it: There's asset-packagist which works fine. And many of us simply don't need any bower packages (apart from those that come with yii2). So we should leave that decision to the developer. The big down point with fxp asset-plugin is, that it's so obtrusive: Once installed, you have no choice but use it (or better: wait for it...). If we really include it, it must be made absolutely sure, that it's only activated on demand and not by default. @and800 I'd say composer makes sense: It's very small and if you don't need it you don't have to use it. But if you need it, it's there and you don't need it locally installed or from another docker image. |
More reasons why we should include composer in any image:
Someone also brought up security concerns when having |
It's currently a Yii 2.0 requirement - asset-packagist has also it's issues.
It's your personal dislike against the asset-plugin speaking here, many of it's issues are solved since a while. My position on this is clear: min
common
|
I believe it when I see it. I think you're trying to make |
I don't really see it as PHP-extensions only. |
Well, that was the initial idea. I must know, because I create the issue #7 for it ;). |
@schmunk42 Could you please state what is wrong with asset-packagist and why it cannot be suitable choice instead of asset-plugin? |
@and800 Please see yiisoft/yii2#8688 (comment) for details. It can be a suitable choice, but you can also run into issues, i.e. if you're requesting a new package for the first time. The very best option would be to use asset-packagist and fxp as a fallback - but that's another issue. |
IMO the best choice is to let the developer decide. Sounds fair to me. No one says fxp plugin is bad. But still not everyone needs it, so it just should be less obtrusive as it is now. But we're getting OT. Back to composer: The main problem I have with composer is the github API key issue. I've used an ugly workaround in our codemix/yii2-dockerbase image, that allows you to pass the API key as env var: https://github.com/codemix/yii2-dockerbase/blob/master/2.0/apache/composer But this is dangerous, as it could encourage people to add their API key at build time. In that case it would become part of the image and that's a no-go. I just can't see a better way how to handle this. |
Isn't that a development only issue? Building images with packages from a In fact, if you run just
But for sure we also wanna run updates in the container. But this also implies a large number of other things to take care about, like caching, host-volume performance, etc... Maybe it makes sense to classify the tools we need a bit more (also related to: #7) composer
fxp
openssh, zlib (git)
mysql, intl, .... (libs)
npm
That's what I meant when saying min/common/full does not only affect runtime extensions. The requirements or expectations are "multidimensional" or let's say |
Yes, but these images here are meant for both, production and development. That's one of the main selling points for a docker workflow. The same image should be used everywhere and we don't need another Not sure, why you bring up |
The workflows are the same, but the images itself are not required to be (that's also related to extends As a valid use-case, take Docker Security scans for example. If you wanna run a production-ready image in a commercial environment like Docker Store you have to pass their scans. This will get harder for every piece you add, if composer (or a required lib) has an open CVE, those would fail and the image would be useless for that purpose.
First, it was an example for a possible |
I would say, that's beyond the scope of our images. Applications who have these kind of requirements should definitely build their own base image from scratch as they surely need additional extensions anyway. It makes no difference if they have to add the 3 extensions we have in That's why I still think, that if we drop Also let's focus on composer here and keep discussion about |
Clearly a goal from my side. Would be feasible with an absolutely
It's a runtime for Yii 2.0 framework, that's not trivial at all, see ICU and gdlib issues. Taking all things into account I'd vote for leaving it out of |
Then we need to automate this during the test. This will also help to see, if composer is problematic from a security perspective, which I very much doubt. |
Let's do an actual scan. Better than guessing what could be. |
@schmunk42 to summarize what we discussed in private, here's what I understand. You suggest that instead of adding composer directly, we provide easy to use installer scripts like:
Note: I don't think we'd need Did I get this right? If so, this solution is maybe really something to consider. The obvious drawback is that we lose the ability to run
|
Currently more meant as an example, yes. But there might be things coming in the future like support for an AP API AuthToken or whatever (there was a short discussion about a trigger from the asset-plugin ... other story).
For now I'd keep the vanilla composer installation in Sidenote: If it's just about composer, you can also run But still, when I build a custom (development) image from
Building a production image could (depending on your workflow) start like so:
Above setup would not even need composer There are various other combinations which might fit better to your workflow. With simple scripts those images can be build very easily. |
As already said elsewhere, images should not differ in this regard. So either we have composer everywhere or nowhere. |
Can we agree, that we don't yet agree in this point :) |
Then I misunderstood your last comment on this in #7:
|
We agree that it should be coherent - maybe coherent will be not to install it by default (we not agree here yet), but to provide a script, with which you can choose to install fxp or not (we agree about the tooling). Finally convinced to hit the button? I fear to reach my GitHub FormPost limit ;) |
I can't follow you anymore. Above I said, that you suggest that we may consider not to install composer. You disagreed and said it's only |
No, I - personally - would not install it in
I agree to that: everywhere we should have the same ways of installing the tools: If We could continue with: Do we need
No, I am respecting your concerns about installing |
All this has already been mentioned or discussed in this or the other thread. I tried to sumarize your view in my comment above. A simple "Yes, that's mostly correct" as response would have been enough. Bringing up the same points over and over again doesn't help. So the last 7 comments or so only add more noise to this discussion which make it discouraging for anyone else to participate. I'm not sure how to proceed. |
We're mixing discussions among different issues and PRs; because they belong together, but anyhow. Let's settle this one: Install composer in all current images. OK. |
But that's not what I said. My comment here was an attemt to find a settlement: Quote:
I've also added what I see as drawbacks and how to workaround. But you obviously missed all of that. |
Maybe we have some misunderstandings ...
I thought your question referenced to the "Note:" paragraph, that's why I answered to this. The rest
is fine.
Yes, that's OK for quick testing.
Yes, 100%. I thought that was obvious. You then came up with #4 (comment) - so I also said OK to |
Composer is installed on the base-image, fxpio/cap is not. |
Yes, please 馃憤
The text was updated successfully, but these errors were encountered: