From: Gary P. <gar...@gm...> - 2010-07-14 17:43:27
|
Yow. I guess that's what happens when two people try to make life easy for the end user by producing one-click installers. There are packaging/installation systems that are supposed to take care of version dependency, but as far as I can tell they come with there own set of problems. This conflict should arise on Windows, too, shouldn't it? Evidently it's rare that someone wants both Vpython and Enthought... one has to wonder if it's worth the effort to fix (if it's fixable at all). Of course, I have my own opinion on that matter. As of today Enthought Python Distribution ships with numpy 1.3, but it doesn't really make sense for Vpython's tail to be wagged by Enthought. On the other hand, if Vpython's installer is overwriting Enthought's installation (or vice versa), that's no good either. James, after you built Vpython, what ended up broken? It may turn out that your solution is the practical one for people in this situation. -g On Wed, Jul 14, 2010 at 1:02 PM, James Mueller <mu...@pi...> wrote: > Bruce, > It is actually a little worse. When I dealt with this two years ago, an > additional problem was that the numpy that came with enthought was different > from the one in the visual package. So, after installing visual, the extra > packages in the Enthought distribution like scipy would crash; if I went > back to enthought's numpy, then visual would crash. I finally found it > easier to install the enthought distribution and then build visual using the > enthought numpy. > -Jim > > On Jul 14, 2010, at 12:47 PM, Bruce Sherwood wrote: > > This suggests that I should make available an optional VPython installer > that checks for a Python being available but not check for the version at > all, leaving it to the person doing the installing the responsibility for > having an appropriate level of Python installed. Gary, as a test you might > install VPython on the standard Python 2.6 (maybe on a different Mac) and > save a copy of the files that go into site-packages, then on your Enthought > machine just copy those files into site-packages. If the Enthought Python is > in fact an instance of Python 2.6, this should work. > > If you do this experiment, please let me know, as I don't have an Enthought > installation to try this on myself. > > Bruce Sherwood > > On Wed, Jul 14, 2010 at 9:55 AM, Gary Pajer <gar...@gm...> wrote: > >> You're right. Here's a snippet of my conversation with them: >> >> ---------------------------------------------------------- >> > The Mac EPD installer has a directory named >> > >> > /Library/Frameworks/Python.framework/Versions/6.2 >> > >> > But the Vpython installer checks to see if exists: >> >> > >> > /Library/Frameworks/Python.framework/Versions/2.6 >> > >> > I rather suspect that the "6.2" is a typo. Simply renaming the >> directory >> > name doesn't work ... stuff doesn't get found. >> >> No, the "6.2" refers to the EPD version, not the python version. It >> sounds like Vpython is either hardcoded to look at that dir, rather >> than use sys.prefix, or you're using the system python to install it. >> -------------------------------------------------- >> >> So the ball is back in Vpython's court: the installer should look for >> sys.prefix ??? >> >> >> >> On Wed, Jul 14, 2010 at 11:43 AM, James Mueller <mu...@pi...> wrote: >> >>> No, this is exactly what they want. 6.2 is the version of the Enthought >>> distribution. It doesn't agree with the python version, so perhaps this is >>> a bad choice on their part, but I don't think they would consider it a bug. >>> >>> -Jim >>> >>> >>> >>> > <ATT00001..txt><ATT00002..txt> > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users > > |