Re: [Framework-Team] hard dependency on PIL?
Hi all, I'm pretty sure most of the people who deploy plone for production will not have many problems with an hard dependency on PIL. I'm a bit concerned about the new users who download the plone installer for MS platforms. At the moment it is very easy for them to install plone and play a bit with the system, will the dependency on PIL complicate the installation process? Will they be forced to download and install a package they don't know at all ? Or we'll include PIL in the windows distribution ? Thanks, vds On Tue, 2006-09-12 at 13:35 +0200, Raphael Ritz wrote: > Wichert Akkerman schrieb: > > Previously Raphael Ritz wrote: > > > >> For two reasons I'm not so sure: > >> > >> 1. PIL isn't necessarily the most trivial package to install > >> and as of now be didn't require our users to fiddle with > >> their Python installation (except for providing an appropriate > >> version). > >> > > > > I suspect (but I can't prove that) that most users will want to use PIL > > and they can be divided in two categories: > > > > - people who just want Plone to work. These people should use the full > > installers, which already install PIL as far as I know. > AFAICT that's correct > > This group > > will also be hurt by image rescaling not working normally > > > but this won't be an issue anyway for those if the above is correct. > > - Plone developers who want to work with the Plone stack directly and > > install from sources (either .tar.gz, .zip or subversion). I would > > expect this group to have enough clue to be able to install PIL as > > well. > > > > > >> 2. I do run sites where we didn't install PIL simply because > >> we aren't specifically dealing with images on them. > >> > > > > That puts you firmly into the second category. > > > > Looking at the code it should be quite simple to remove the hard PIL > > dependency though. > I didn't want to imply that this would be hard to do. > All I'm asking in the end is whether this was a concious decision > or just an oversite as this differs from our current policy. > > A (very quick) look at the code does suggest that > > doing so might introduce a security risk: it will also remove a real > > sanity-check that a member portrait is an actual image. Something which > > is nicely exploited by the spam we've been seeing lately on plone sites. > > > > > that's a good point indeed but maybe just one more thing to > educate people when it comes to best practices regarding > dev boxes versus production sites. > > I could live with PIL being required but I would also > like to hear opinions from those who didn't comment > on this yet. > > Just my 2 cents > > Raphael > > Wichert. > > > > > > > ___ > Framework-Team mailing list > Framework-Team@lists.plone.org > http://lists.plone.org/mailman/listinfo/framework-team > -- Vincenzo Di Somma REFLAB srl design, development and consulting T: +39 349 756 54 60 E: [EMAIL PROTECTED] W: www.reflab.com Weblog: http://www.reflab.com/blogs/vdsblog signature.asc Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] hard dependency on PIL?
Wichert Akkerman schrieb: Previously Raphael Ritz wrote: For two reasons I'm not so sure: 1. PIL isn't necessarily the most trivial package to install and as of now be didn't require our users to fiddle with their Python installation (except for providing an appropriate version). I suspect (but I can't prove that) that most users will want to use PIL and they can be divided in two categories: - people who just want Plone to work. These people should use the full installers, which already install PIL as far as I know. AFAICT that's correct This group will also be hurt by image rescaling not working normally but this won't be an issue anyway for those if the above is correct. - Plone developers who want to work with the Plone stack directly and install from sources (either .tar.gz, .zip or subversion). I would expect this group to have enough clue to be able to install PIL as well. 2. I do run sites where we didn't install PIL simply because we aren't specifically dealing with images on them. That puts you firmly into the second category. Looking at the code it should be quite simple to remove the hard PIL dependency though. I didn't want to imply that this would be hard to do. All I'm asking in the end is whether this was a concious decision or just an oversite as this differs from our current policy. A (very quick) look at the code does suggest that doing so might introduce a security risk: it will also remove a real sanity-check that a member portrait is an actual image. Something which is nicely exploited by the spam we've been seeing lately on plone sites. that's a good point indeed but maybe just one more thing to educate people when it comes to best practices regarding dev boxes versus production sites. I could live with PIL being required but I would also like to hear opinions from those who didn't comment on this yet. Just my 2 cents Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] hard dependency on PIL?
Previously Raphael Ritz wrote: > For two reasons I'm not so sure: > > 1. PIL isn't necessarily the most trivial package to install > and as of now be didn't require our users to fiddle with > their Python installation (except for providing an appropriate > version). I suspect (but I can't prove that) that most users will want to use PIL and they can be divided in two categories: - people who just want Plone to work. These people should use the full installers, which already install PIL as far as I know. This group will also be hurt by image rescaling not working normally - Plone developers who want to work with the Plone stack directly and install from sources (either .tar.gz, .zip or subversion). I would expect this group to have enough clue to be able to install PIL as well. > 2. I do run sites we we didn't install PIL simply because > we aren't specifically dealing with images on them. That puts you firmly into the second category. Looking at the code it should be quite simple to remove the hard PIL dependency though. A (very quick) look at the code does suggest that doing so might introduce a security risk: it will also remove a real sanity-check that a member portrait is an actual image. Something which is nicely exploited by the spam we've been seeing lately on plone sites. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] hard dependency on PIL?
Wichert Akkerman schrieb: Previously Raphael Ritz wrote: Up to now we have PIL as a soft dependency in Plone/AT so the question is whether this change is intended or just an oversite. As PIL isn't part of a standard Python distribution I personally would prefer to keep this a soft dependency. Considering the amount of problems users report who don't have PIL installed and the fact image handling pretty much already requires it (esp. with the current kupus offering resized images) perhaps making PIL a hard dependency is worth it. For two reasons I'm not so sure: 1. PIL isn't necessarily the most trivial package to install and as of now be didn't require our users to fiddle with their Python installation (except for providing an appropriate version). 2. I do run sites we we didn't install PIL simply because we aren't specifically dealing with images on them. If I need PIL I do know how to install it but I would find it annoying if I would always have to install PIL simply to get Plone up and running even if I know I won't really benefit from the features provided through PIL. But maybe that's just me ... Raphael Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] hard dependency on PIL?
On Tue, 2006-09-12 at 10:00 +0200, Wichert Akkerman wrote: > Previously Raphael Ritz wrote: > > Up to now we have PIL as a soft dependency in Plone/AT > > so the question is whether this change is intended or just > > an oversite. > > > > As PIL isn't part of a standard Python distribution I personally > > would prefer to keep this a soft dependency. > > Considering the amount of problems users report who don't have PIL > installed and the fact image handling pretty much already requires it > (esp. with the current kupus offering resized images) perhaps making > PIL a hard dependency is worth it. I see your point but I would like to avoid an hard dependency on PIL. vds -- Vincenzo Di Somma REFLAB srl design, development and consulting T: +39 349 756 54 60 E: [EMAIL PROTECTED] W: www.reflab.com Weblog: http://www.reflab.com/blogs/vdsblog signature.asc Description: This is a digitally signed message part ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] hard dependency on PIL?
Previously Raphael Ritz wrote: > Up to now we have PIL as a soft dependency in Plone/AT > so the question is whether this change is intended or just > an oversite. > > As PIL isn't part of a standard Python distribution I personally > would prefer to keep this a soft dependency. Considering the amount of problems users report who don't have PIL installed and the fact image handling pretty much already requires it (esp. with the current kupus offering resized images) perhaps making PIL a hard dependency is worth it. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] hard dependency on PIL?
Hi Hanno and framework team members, just a quick question in passing: looking at plip 148 (move to CMF 2.1) I noticed that Plone has a hard dependency on PIL there at the moment. Moving 'scale_image' into CMFPlone/utils.py resulted in an unconditioned from PIL import Image which of course fails if PIL isn't installed. Up to now we have PIL as a soft dependency in Plone/AT so the question is whether this change is intended or just an oversite. As PIL isn't part of a standard Python distribution I personally would prefer to keep this a soft dependency. Comments anyone? Raphael ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team