I would vote for pip based installation. But instead of using pip with requirements.txt, I would use pipenv with a Pipfile. I use it in my projects already (not as a buildout replacement right now), but it gives more control and has some nice features handling virtual environments and dependencies. And it's the new official standard for installing Python packages.
Just a note, about the docker one, please keep in mind that the 'official' one may change in the future (we have already some plans).
One possibility which we are still thinking about is for example to 'split' into two images, one which is more closed (but improved) to our current one and another one which is more 'focused on production'.
Also we will introduce multi-stage builds.
1 Like
I think it should be based on what is the most useful outcome. If the pip based approach is the better approach and is feasible to implement comfortably within 2 to 3 weeks during GSoC then I'd encourage that (I'm absolutely uninformed in this area).
I have the feeling that the docker approach isn't widely used in the community yet, whatever is implemented by plonecli will become the standard.
@pigeonflight If we'd recommend pip based approach instead of the buildout based approach, would you still be able to be the primary mentor for the project (to ensure good plonecli user experience)? I could be available the help with pip related issues.
(And just to be clear, pip approach already works, but just requires some extra steps to go around known issues with the current package versions. Pipenv would also be ok, it would require one more step to generate pipenv file from pip, but would ensure that all versions are truly pinned up to checking package hashes with pipfile.lock. requirements.txt is currently easier to maintain for new Plone releases with buildout.requirement.)
1 Like
With some support from the community on the pip approach I think I'd be okay mentoring otherwise. I'll probably try out the pip based approach within the next few weeks anyway. Sounds like @tmassman would be another good resource for this.
I will jump in here to remind us all that the mentor for a project need not be the one who has all the answers on how to accomplish the project. The job of a mentor is to facilitate the student in finding help. To keep the student on track, and assist them in resolving blocking issues when they are having trouble. The mentor does not need to be the one who always has the answers, but should be ready and willing to help find the community member who does.
2 Likes
Just as an idea to add to this existing project, would it be useful if we could also write integration and functionality tests(also other tests if required) to ensure it doesnt break the codeabase? Or will that be covered by a continuous deployment platform such as gitlab?
We use both Travis-CI and Plone Jenkins. But CI does not write the tests for you.
Both plonecli and bobtemplates.plone have place for tests and most of the existing features tested. Writing tests for new features is best practice. Especially in GSOC, which is all about learning best practices.
3 Likes
I just have a quick question. I have saved the link to my draft proposal for this idea+ adding the missing templates for GSoC on the GSoC proposal submission portal. Could anyone review my draft proposal that I have submitted? Thanks!
@mrsaicharan1 Please, double check that the draft is shared properly. (I was unable to see it just as a mentor and therefor asked for permission. Please, don’t give us edit permissions. We only need to read and comment [and edit permissions make mobile UI more complex].)
1 Like
I realized that this discussion is related when (possibly) choosing to implement pip based docker approach over buildout based:
Currently the configuration (zope.conf) and startup scripts are being generated by a buildout recipe (plone.recipe.zope2instance). When Plone is installed with pip, those are not being generated and a replacement is needed. (zope.conf could possibly be generated with jinja2 templates similarly to other templates in bobtemplates.plone, instance scripts could be merged form plone.recipe.zope2instance to plonecli – as I did in my branch earlier)
1 Like
@datakurre Yes, I have taken care of it. I have now given the right access. You can now view it as a mentor.
@pigeonflight @datakurre
I'm a bit confused about the use case of plonecli dockerize.
Is it supposed to create a new Docker container using the plone.docker image (or the pip-based image) and then allow the developer to create a site or an add-on package within the container, also allowing them to save the changes made in the container in the form of a new image and finally load this image for deployment?
Or is it supposed to create an image out of the site/add-on packages previously created by the user?
I may be missing something out here, but wouldn't the only difference while implementing this project using the pip-based approach (as opposed to the buildout-based approach) be using the pip-based image https://github.com/ericof/docker-plone, instead of plone.docker and including the command to install using pip install -r requirements.txt, instead of bin/buidlout in the Dockerfile?
I think the concept behind shipping the site would be first creating the plone site and then running a command, which would then containerize the buildout and provide a certain command to dockerize the site. I guess dockerizing buildout would be the best practice. Running ./bin/buildout would just update the changes and packages required which I believe would be a good implementation of it.
Pip based approach seems a good option but I've small doubt if we choose pip based docker approach, since buildout can easily handle version conflicts and after every ./bin/buildout it checks and updates the dependencies or any packages for that matter.
How are we going to accomplish that in pip based docker?
I think it's necessary to build something which can upgrade to latest version.
I mean running pip install Pillow>=3.3.0 would install the latest version for the new user but what about existing user who already has Pillow 3.3.0 installed. It will say the version is satisfied.
I'm trying to relate Pillow to any Plone core dependecies or any package for that matter.
@datakurre @pigeonflight
1 Like
I have submitted my GSoC Project Proposal on Command-Line Plone tools .Please review it.
Thanks 
In your example pip works as expected. Pillow 3.3.0 is good for requirement Pillow >= 3.3.0. Yet, upgrade can be forced with pip install -U.
You should time the difference in adding a custom package for buildout base default docker image compared to the pip based docker image. it should be significant in benefit of pip based image (because it only adds those new packages into virtualenv, but buildout must do much more).
Buildout exists, because Plone predates any usable version of Python virtualenvs or pip (not to mention many issues previous issues with Pyhon packaging in overall). That said, the situation now with wheel packages, virtualenv support in core (in Python 3), pip and pipenv, the situation is so much better that for some time it has been hard to justify the requirement to learn buildout for Plone development. Especially when we have not managed to keep buildout itself in par with pip (buildout is much slower and last time I checked its "offline support" is broken with wheel packages).
2 Likes
Clubbed along with this idea, util, as mentioned in the bobtemplates.plone improvement goals, is it being referred to utilities? I've assumed it is utilites but I'm still a bit confused to what it exactly is. I'd like to update the info in my proposal asap as the deadline is less than 2 days away. Also, after the update of the util section, I'd be glad if I could get a final review on my proposal. Thanks in advance!
Yes, it is Utilities which MrTango has mentioned as the missing template to the bobtemplates.plone.
Hope this helps.
1 Like