Is time to remove ZendSkeletonApplication submodules?
Locked
12
12
 
|
Hi all,
Anybody know a reason that prevents the removal of the vendor directory as well as the ZendSkeletonApplication submodules installation workflow? Seem to me that making ZendSkeletonApplication installation similar to what right now is zf-apigility-skeleton installation we will gain in uniformity. I could create PRs to deal with this, but as Maks3w point me out (https://github.com/zendframework/ZendSkeletonApplication/pull/235), an email here will allow others developers give theirs opinion about this issue. Thanks Frank |
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
There all still many people which dont use composer...(look through different zf2 modules where people have problems when not using composer) Let all options open for people. Am 20.01.2014 20:52 schrieb "Frank Cancio" <[hidden email]>:
|
|
|
I don't get the advantage of using git submodules over composer regards the accessibility, both need Internet access. Can you be more explicit about the problem people have with zf2 modules when not using composer and how git submodules could help us to solve those problems?
On Mon, Jan 20, 2014 at 6:33 PM, Martin Keckeis <[hidden email]> wrote:
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
On 20 January 2014 21:48, Frank Cancio <[hidden email]> wrote:
Just a note additional to that: assuming that the module is already autoloaded, you don't need any "special rule" even if you are not requiring a module via composer. For example, if you copy-pasted a module in `module/MyStuff`, you can simply use composer's json to produce an autoloader for that: {"autoload":{"psr-0":{"MyStuff":"module/MyStuff/src"}}} Or you can setup your zf autoloader upfront if you prefer that. I wouldn't get rid of the module cloning workflow though - it makes it simpler to work for companies that don't want to start using satis for smaller projects. |
|
|
On Mon, Jan 20, 2014 at 7:43 PM, Marco Pivetta <[hidden email]> wrote:
Maybe I don't express well myself... but I'm asking for inconveniences of get rid of the git submodule workflow as a way to pull ZF2 **while installing ZendSkeletonApplication**, I'm not asking for get rid of the git submodule workflow as a way to install ZF2 modules.
My question is, what benefices provide to us over its composer alternative the support of `git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive`?
What I propose is: - Removing the section https://github.com/zendframework/ZendSkeletonApplication#using-git-submodules from the README.md
- Remove `vendor` dir from the ZendSkeletonApplication github repo - Remove git submodule configuration - Adjust root .gitignore file What we will gain doing that? Well, beside the above mentioned uniformity with installation ways of zf-apigility-skeleton, make easier the maintenance. Right now after do `git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive` one end with a very old ZF2 version in 'vendor/ZF2' dir, more specifically this commit: https://github.com/zendframework/zf2/commit/6022f490695b1c835070d9e5a81b45dc20b4a51c
With these changes we will not be forbidden users install theirs own modules using git submodules workflow. The only effect will be that users can't use `git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive` out the box anymore (they actually can configure git submodules in theirs local clones to pull ZF2). My intention is end with similar installation alternatives in zendframework/ZendSkeletonApplication and zfcampus/zf-apigility-skeleton. So if at the end we decide that for some reason is useful keep the git submodules workflow as a way to pull ZF2 as part of the installation process of ZendSkeletonApplication, we should consider add it to the zf-apigility-skeleton too.
Thanks! Frank |
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
This post has NOT been accepted by the mailing list yet.
On 21 January 2014 04:07, gsc-frank [via Zend Framework Community] <[hidden email]> wrote:
Whoops, my bad! :|
There's some companies/users that still don't use composer for <insert-reason-i-do-not-understand-here/>. And yes, composer does not support package signing yet, so that is also quite a problem. I'm overall +1 for removing this way of installing things - I don't see a (meaningful) way of building larger applications in PHP without composer nowadays.
Documentation needs adjustments as well
Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ |
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
In reply to this post by gsc-frank
2014/1/20 Frank Cancio <[hidden email]>
You are right about that. But e.g. it can be that a domain or port is blocked and another not.
I never used the submodules to install and i don't know how much people actually use it. But through it's a skeleon, many different starting points are good IMO.
I don't see the effort here to remove it, through it's not that much code. |
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
In reply to this post by gsc-frank
CONTENTS DELETED
The author has deleted this message.
|
|
|
I don't think this achieves anything and only limits the installation options. G On Tue, Jan 21, 2014 at 9:10 AM, Stefano Torresi <[hidden email]> wrote:
|
|
|
Thanks to all for your replies. So right now we are delivering to users that choose git submodule workflow a stale ZF2 version, the only way to guarantee that this will not happen again is be very disciplined and with each release of ZF2 update ZendSkeletonApplication ZF2 submodule conf, mean waste time in maintenance. In change of what? Martin point me some domain and port blocking stuff, still git submodule workflow use 443 and 9418 while composer workflow use 80 and 9418, the only different is that one use github.com and the other use packagist.org + github.com domain.
I think that whatever thing we decide here, will get changes to ZendSkeletonApplication or to zf-apigility-skeleton On Tue, Jan 21, 2014 at 7:15 AM, Gary Hockin <[hidden email]> wrote:
|
|
|
Why not just update ZendSkeletonApplication with latest ZF2 submodule and fix any bugs that result? I refuse to use composer for my ZF2 projects. It's specifically rejected by my enterprise requirements.Richie Bartlett Jr (バートレット理路) On Wed, Jan 22, 2014 at 1:14 AM, Frank Cancio <[hidden email]> wrote:
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
Enterprise requirements??? #areyousure
I highly recommend using Composer. Eddie Abou-Jaoude, BEng, MSc Jaoude Studios Ltd LAMP & Zend Framework Consultant On 21 Jan 2014, at 16:23, バートレット理路 <[hidden email]> wrote:
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
With slow moving corporations, it's quite often that you can't use the latest and best tools. I'm just happy we can finally use PHP 5.4 here as of January for new projects (even if it's 5.4.14 and getting a bit aged)
We can't technically use composer, as it's not on the allowed applications list, and neither getcomposer.org nor packigist.org are whitelisted for corporate network access.
So, I can believe that it's the same elsewhere where corporate IT policies/lawyers have reign. For example, we are allowed only to use very specific versions of YUI, jQuery, ZF2 (not the entire library, only certain components are allowed x.x), etc. And with the deployment process taking anywhere from 3-12 months after we make a fix / develop new features -- we tend to follow those allowed version numbers to the T to prevent it being bounced back by legal, or certification teams during the process, delaying deployment further.
We got access to PHP 5.3 just last year. So that was a wonderful day for us. On Tue, Jan 21, 2014 at 8:27 AM, Eddie Abou-Jaoude <[hidden email]> wrote:
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
With slow moving corporations, it's quite often that you can't use the latest and best tools. I'm just happy we can finally use PHP 5.4 here as of January for new projects (even if it's 5.4.14 and getting a bit aged)
We can't technically use composer, as it's not on the allowed applications list, and neither getcomposer.org nor packigist.org are whitelisted for corporate network access.
So, I can believe that it's the same elsewhere where corporate IT policies/lawyers have reign. For example, we are allowed only to use very specific versions of YUI, jQuery, ZF2 (not the entire library, only certain components are allowed x.x), etc. And with the deployment process taking anywhere from 3-12 months after we make a fix / develop new features -- we tend to follow those allowed version numbers to the T to prevent it being bounced back by legal, or certification teams during the process, delaying deployment further.
We got access to PHP 5.3 just last year. So that was a wonderful day for us. On Tue, Jan 21, 2014 at 10:09 AM, Garbage Dump <[hidden email]> wrote:
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
Wow were do you work? That does not sound very Agile or Continuous Delivery (3-12months) #Ifeelyourpain :(
Eddie Abou-Jaoude, BEng, MSc Jaoude Studios Ltd LAMP & Zend Framework Consultant On 21 Jan 2014, at 18:10, Carlos Koch <[hidden email]> wrote:
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
In reply to this post by gsc-frank
Hello,
On Tue, Jan 21, 2014 at 9:14 AM, Frank Cancio <[hidden email]> wrote:
This is my fault. I was being very meticulous about keeping this up to date and in sync with upstream releases (including tags), but fell behind and haven't caught up.
This is what I was doing for a long time, and it was not a problem at all. It literally adds maybe 5 or 10 seconds to the tagging process for the skeleton. The larger issue has just been a lack of time dedicated towards maintaining this. I'll see if I can get the skeleton tagged and up to date in the next couple weeks. Honestly knowing that it's behind is what has been keeping me from doing it, so once it's caught up, I'm more inclined to stay up to pace with the releases. Like I said, it only takes a few seconds if someone bugs me to do it.
Personally, I still like being able to clone in a single command and get any release version + skeleton of ZF2 that I want. While there may not be a large subset of users who prefer or use the submodule, I don't think that alone justifies removing a viable, single-command installation option. I see less purpose in removing it.
Thanks, Evan Coury |
|
|
On Tue, Jan 21, 2014 at 11:01 PM, Evan Coury <[hidden email]> wrote:
I can help, I suppose that if you explain me what to do I can create some PRs saving you time.
Hmm, evidently this can't be achieved with composer outbox.
After read all the scary corporation thing that Carlos wrote and take in consideration what Evan said about "get any release version", I think now that remove submodule workflow installation of ZendSkeletonApplication is not such good idea ;)
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
On Wed, Jan 22, 2014 at 2:55 AM, Frank Cancio <[hidden email]> wrote:
Why so? You can install specific version from composer (https://getcomposer.org/doc/01-basic-usage.md#package-versions). And it's two commands instead of one for majority of users and three steps (clone, change composer.json version, composer). |
|
|
On Wed, Jan 22, 2014 at 7:18 AM, Tomáš Fejfar <[hidden email]> wrote:
You are right, I don't see how with git submodule you can "clone in a single command and get any release version + skeleton of ZF2". At first I thought that you can do that with something like "git clone git://github.com/zendframework/ZendSkeletonApplication.git --recursive --branch RELEASE_NAME", but I tested now and RELEASE_NAME can't be a tag (versions identifiers).
Just for the records... in cases where you don't need different ZendSkeletonApplication and ZF2 versions, the second step could be a ZendSkeletonApplication checkout (bringing to the working dir the appropriate composer.json file) instead of a composer.json edit.
|
Re: Is time to remove ZendSkeletonApplication submodules?
|
|
I apologize, I thought --branch would work with any treeish, but it appears I was mistaken. Back when I was doing benchmarks between versions, I was running git checkout TAG && git submodule update, which admittedly is not any different than the same process with composer. That's not my primary point, though. I just don't see value in limiting the options, especially if I have no problem getting back into maintaining the skeleton tags. Thanks, Sent from my phone. Please excuse any typos or unintentional auto-corrections. On Jan 22, 2014 5:10 PM, "Frank Cancio" <[hidden email]> wrote:
|
«
Return to ZF Contributor
|
1 view|%1 views
| Free forum by Nabble | Edit this page |