win98, Py234
Did anybody try to use wxversion.require() in all the modules of
an application/project?
Even if all the modules require the same and a single wxPython
version, it does not seem to work.
I got:
File "C:\PYTHON23\lib\site-packages\wxversion.py", line 61, in require
assert not sys.modules.has_key('wx') and not sys.modules.has_key('wxPython'), \
AssertionError: wxversion.require() must be called before wxPython is imported
Jean-Michel Fauth, Switzerland
Jean-Michel Fauth wrote:
win98, Py234
Did anybody try to use wxversion.require() in all the modules of
an application/project?
Even if all the modules require the same and a single wxPython version, it does not seem to work.I got:
File "C:\PYTHON23\lib\site-packages\wxversion.py", line 61, in require
assert not sys.modules.has_key('wx') and not sys.modules.has_key('wxPython'), \
AssertionError: wxversion.require() must be called before wxPython is imported
That is by design. It is meant to be used only once, at the very begining of an application.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
That is by design. It is meant to be used only once, at the very begining of an application.
I think I remember this being discussed, but I'm not sure I like it. A module can require a version just as much as an app. Could it be allowed, but raise an error if whatever version is first selected doesn't fit the requirements of previous calls?
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
I could see this as being very problematic. I have no idea what the solution is, so I'll try and explain the issue in great detail from the point of PythonCard.
I will definitely need to have a requires and possibly even a wx.VERSION check in model.py, which is the main module that all PythonCard programs import. Some of the other framework modules rely on model.py as well, so they also import model.py, making it a good place to do asserts and exit gracefully, but to avoid circular dependencies, many framework modules don't import model.py. The current code I'm using is below, which is supposed to protect the user from trying to use an older version of Python and wxPython. The code will need to be extended to include an import version, wxversion.require() within a try block. Perhaps we can come up with a generic recipe that all of us can use to deal with this requires issue?!
There is a further complication in that if wx is needed in a framework module or PythonCard application, the import wx is sometimes done before the from PythonCard import model, etc. and sometimes afterwards. Here are some examples.
# PythonCard/samples/minimal/minimal.py
from PythonCard import model
# PythonCard/samples/life/life.py which is a more complicated sample that needs to import wx for sizers
import os, sys
import shutil
import wx
import util as lifeutil
from PythonCard import clipboard, configuration, dialog, graphic, model, util
# in PythonCard/components/button.py, I have the following imports
import wx
from PythonCard import event, widget
As mentioned above, to avoid circular dependencies, most of the framework modules DO NOT import PythonCard/model.py. And again, sometimes wx is imported first and sometimes it is imported after other PythonCard modules.
So, I can see a variety of problems here. Even though I can isolate the code needed for the framework in one spot, there are still going to be import wx statements in other modules, which implies every single module is going to need to have the same code block. But then the namespace wrangling is only supposed to be done once. More likely, I'm going to need one module that all other modules import first and its sole purpose in life is to import wx, do the appropriate requires, fail gracefully if conditions aren't met, etc.
I haven't downloaded the 2.3.x daily build yet, and won't until after the coding sprint is over this weekend, so I won't be able to test anything on Windows or Mac until next week.
ka
On Oct 20, 2004, at 12:13 PM, Chris Barker wrote:
Robin Dunn wrote:
That is by design. It is meant to be used only once, at the very begining of an application.
I think I remember this being discussed, but I'm not sure I like it. A module can require a version just as much as an app. Could it be allowed, but raise an error if whatever version is first selected doesn't fit the requirements of previous calls?
---
# top of PythonCard/model.py
import os, sys
# KEA 2004-08-09
# assert some minimum requirements and attempt to exit cleanly
# if they aren't met
try:
# some things might work with lesser
# versions, but this is a reasonable base
assert sys.version_info >= (2, 3)
# sys.modules relative path fix
sys.path[0] = os.path.abspath(sys.path[0])
#sys.path = [os.path.abspath(p) for p in sys.path]
import wx
assert wx.VERSION >= (2, 5, 2, 8)
except:
from wxPython.wx import wxPySimpleApp, wxFrame, wxMessageDialog, wxICON_EXCLAMATION, wxOK, wxVERSION_STRING
app = wxPySimpleApp()
frame = wxFrame(None, -1, "Minimum Requirements Not Met")
#frame.Show(1)
message = "PythonCard minimum requirements:\nPython 2.3 and wxPython 2.5.2.8\n\n" + \
"You are using Python %s\nand wxPython %s.\n\nClick OK to exit." % (sys.version, wxVERSION_STRING)
dialog = wxMessageDialog(frame, message,
"Minimum Requirements Not Met",
wxICON_EXCLAMATION | wxOK)
dialog.ShowModal()
dialog.Destroy()
#app.MainLoop()
sys.exit(0)
Chris Barker wrote:
Robin Dunn wrote:
That is by design. It is meant to be used only once, at the very begining of an application.
I think I remember this being discussed, but I'm not sure I like it. A module can require a version just as much as an app. Could it be allowed, but raise an error if whatever version is first selected doesn't fit the requirements of previous calls?
Yes, I can do that. And, in fact, I had seen it in the pygtk.py version selector and so it was already on my ToDo list and I have it partially done.
Keep in mind however that wxversion's main purpose in life is *not* version checking but *modifying* the sys.path to allow a requested version of wxPython to be imported. (Perhaps "require" is not a very good name for the function..., how about "request" or "select"?) Therefore it only makes sense to me to use it from the very begining of an application. As my father-in-law always says, "Once the horse is out (you've done import wx) closing the barn door doesn't do much good." 
Anyway, I think that if library modules need to restrict themselves to a particular set of versions then they should do it with wx.VERSION and/or wx.PlatformInfo. Also, I don't forsee every app using wxversion, but only those that want to stay behind with a not-current release of wxPython. We'll see...
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Kevin Altis wrote:
I will definitely need to have a requires and possibly even a wx.VERSION check in model.py, which is the main module that all PythonCard programs import. Some of the other framework modules rely on model.py as well, so they also import model.py, making it a good place to do asserts and exit gracefully, but to avoid circular dependencies, many framework modules don't import model.py. The current code I'm using is below, which is supposed to protect the user from trying to use an older version of Python and wxPython. The code will need to be extended to include an import version, wxversion.require() within a try block.
I would leave it doing checks of wx.VERSION and let the users optionally select the version to import in their own code by using wxversion before they import PythonCard or wx.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Hi Robin,
Chris Barker wrote:
Robin Dunn wrote:
That is by design. It is meant to be used only once, at the very begining of an application.
I think I remember this being discussed, but I'm not sure I like it. A module can require a version just as much as an app. Could it be allowed, but raise an error if whatever version is first selected doesn't fit the requirements of previous calls?
Yes, I can do that. And, in fact, I had seen it in the pygtk.py version selector and so it was already on my ToDo list and I have it partially done.
Keep in mind however that wxversion's main purpose in life is *not* version checking but *modifying* the sys.path to allow a requested version of wxPython to be imported. (Perhaps "require" is not a very good name for the function..., how about "request" or "select"?) Therefore it only makes sense to me to use it from the very begining of an application. As my father-in-law always says, "Once the horse is out (you've done import wx) closing the barn door doesn't do much good."
Anyway, I think that if library modules need to restrict themselves to a particular set of versions then they should do it with wx.VERSION and/or wx.PlatformInfo. Also, I don't forsee every app using wxversion, but only those that want to stay behind with a not-current release of wxPython. We'll see...
It is exactly because of what your father in law says that I like to avoid "we'll see" as much as possible. Because by the time we know the answer, the horse will not only be out of the barn, but a good ways down the field. Realistically, we won't know how the community as a whole will take the change for 6 months to a year after it's released, and after that amount of time (including it's release in a stable version), if it isn't used as expected, how can the horse be put back into the stable? Not without seriously upsetting some folks and further exacerbating the impression of wxPython as an unstable toolkit. Once it is out the door, people will begin relying on it, and undoing the change later will cause much more grief than rethinking things now will. That's why I think this is way too much of a big deal to take a "try it and see" approach.
I think we can, and should, find a solution that makes this whole upgrading process smoother, less painless, and more transitionary. But 2.5 is out the door, and we're already nearing 2.6, and I think rushing to have a solution for 2.6 is not really a good idea, especially when there is significant confusion as to how this new feature should and should not be used. Regardless of what wxversion is really intended for, the consensus I'm hearing from others is one of using it for "quality control" purposes, not as a crutch or temporary measure. And to be honest, while some people may feel that forcing users to "deal with these compatibility issues" is a good thing, it looks to me that the process of dealing with these issues will neither be smooth nor painless for the user/developer. And it's not clear, particularly on Windows/Mac, if the benefits there outweigh the pain.
In short, I don't think this solution is a clear winner, and to me that usually means it's better to hold off until we're sure we've got it right.
You said in another message that due to wxPython's limited resources, it can't afford to have a more structured development process. On the contrary, I think as it grows it can't afford not to. If there aren't enough resources to handle that, *that* is the problem we need to find a solution for. The alternative is that as wxPython grows more and more, changes will get more and more rushed, simply because these changes must be done when time allows, and there aren't enough resources to put together a better/more robust solution. It's a basic issue of quality vs. resources, IMHO. Change is constant, and growth is pretty much guaranteed for this project. The only real question is how to deal with said change: whether there should be an increase in resources, or a decrease in quality. One or the other will have to happen. Find a way to increase resources, and I'm pretty sure life will get a whole lot better for wxPython, and wx in general.
I've got some ideas on that, but for the moment, I'll stop here, so as to stop rambling.
Thanks,
Kevin
On Oct 21, 2004, at 2:49 PM, Robin Dunn wrote:
Robin Dunn wrote:
Chris Barker wrote:
A module can require a version just as much as an app. Could it be allowed, but raise an error if whatever version is first selected doesn't fit the requirements of previous calls?
Yes, I can do that. And, in fact, I had seen it in the pygtk.py version selector and so it was already on my ToDo list and I have it partially done.
cool.
Keep in mind however that wxversion's main purpose in life is *not* version checking but *modifying* the sys.path to allow a requested version of wxPython to be imported. (Perhaps "require" is not a very good name for the function..., how about "request" or "select"?) Therefore it only makes sense to me to use it from the very begining of an application. As my father-in-law always says, "Once the horse is out (you've done import wx) closing the barn door doesn't do much good."
Anyway, I think that if library modules need to restrict themselves to a particular set of versions then they should do it with wx.VERSION and/or wx.PlatformInfo.
fair enough. I would like there to be a standard method for doing this, rather than everyone having to roll their own. In the case of:
"it only works with 2.5.2.2"
it's really simple, but if you have a range of versions, or a list of version, there's a little more to it (only a little, I know). Enough that I'd like to have the code in wx, rather than in my own library, and I'd like to see it have the same syntax at wx.require(). Maybe we need both:
wx.select()
and
wx.require()
wx.select() could only be called once, before any "import wx".
> Also, I don't forsee every app using wxversion, but
only those that want to stay behind with a not-current release of wxPython.
well, I don't know that I'll know whether I need it to stay behind when I first run it. If I update it to keep up with wxPython versions, I'll change the line.
Kevin Ollivier wrote:
Realistically, we won't know how the community as a whole will take the change for 6 months to a year after it's released, and after that amount of time (including it's release in a stable version),
I'm not sure about that. I do think we need it in an unstable version, and that as many of us need to use it as possible, to see how it goes. What other option do we have to evaluate a new feature? It should probably bear evaluation before releasing it in a stable version, however.
undoing the change later will cause much more grief than rethinking things now will. That's why I think this is way too much of a big deal to take a "try it and see" approach.
This is true, but we can re-think things 'till the cows come home (keeping with the barnyard metaphors), and we'll never know if it meets people's needs until people start testing it, and it can't get tested 'till it gets into a (unstable) release.
In short, I don't think this solution is a clear winner, and to me that usually means it's better to hold off until we're sure we've got it right.
I'm still not sure what you're main point is. It seems we all agree that at SOME point, wxPython will come out with an incompatible version. You'd have liked that not to happen 'till version 3.0, but now it's happened at 2.5.*. In any case, ti's really a matter of choosing your numbers. I thought 2.4.* was a stable version, 2.5.* is a development version, and therefore subject to change, and 2.6.* will be the next stable version. This has all gotten complicated, because the 2.5* series has a lot of stuff it many of us want to use, particularly on OS-
X, where 2.4.* is essentially useless.
In any case, it seems the only place you and I disagree is on how frequently incompatible versions come out. However, they WILL come out, and we need a way to handle that. Ideally, wxPython should be in sync with Python releases. Then I'd just upgrade them both together, but that's not going to happen for a while.
The reason we need to have wx.require() ( or wx.select() ) in 2.6 is that then when 3.0 comes out, 2.6 based apps can be using it, and we can all add 3.0 to our systems without breaking any 2.6 based apps. Personally, I want it now, for upgrades from 2.5.x to 2.5.x+1 as well. I'm guessing that you'd like to see a wx.require() that ONLY deals with "major" versions, but I'm not sure I've seem you write that explicitly.
You said in another message that due to wxPython's limited resources, it can't afford to have a more structured development process. On the contrary, I think as it grows it can't afford not to.
Well, it seems that you want to think things out more before introducing them into a release. That's a great idea, but who's going to do all this thinking? At the moment we have Robin doing most of the work, and small handful of us on wxPython-dev testing things and contributing ideas. If Robin doesn't put code out there for us to test, how are we going to think about it more? This is like the "tracer Bullets" from _The Pragmatic Programmer_: we need something working to try before we can know if the idea is on-target.
Again, as we don't' seem to sure how this is going to be used, we need to clarify the various user types. Here are some I identify:
1) folks on wxPython-dev:
We want to be able to run various versions, and have them all installed at once. wx.require() is a great way to handle this. On the other hand, we're also sophisticated enough to develop and use our own schemes for switching between versions.
2) end users, who may not even know their app is written in Python:
These folks should be given a package built with Py2exe Py2app, or whatever, and this is a non-issue there too.
3) wxPython programmers:
These are folks that are using wxPython, but not involved in it's development. They have less need to run multiple versions, but they still have some need. They nay have apps and utilities already written that they don't want to change when they upgrade, they may see examples in the Wiki that use a different version than they are using, etc. wx.require would be very helpful to these folks.
4) Managed users:
These are folks that will run various wxPython based programs on their machines. They haven't written them themselves, but will use them , and have newer ones installed later. The programs and the wxPython installers will have be provided to them. This is a group I am targeting. Folks in my organization that I give small utilities to. I don't mind having to give them a new wxPython installer when I give them a new app that requires and updated version, but I want the stuff I gave them last year to still work also.
Honestly, I'll probably put a wx.requires() line in every app I write, just like I put a python version number in every #! line.
> Find a way to
increase resources, and I'm pretty sure life will get a whole lot better for wxPython, and wx in general.
I've got some ideas on that,
This, I want to hear!!
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Hi Chris,
The below is obviously going to take the discussion in a different direction, so I moved this to another topic.
> Find a way to
increase resources, and I'm pretty sure life will get a whole lot better for wxPython, and wx in general.
I've got some ideas on that,This, I want to hear!!
As a start, we setup a simple Mozilla-like system of donations with perks, like CDs or maybe a neato t-shirt or something. (With a nice slogan that pokes at Java, like "Write Once, Native Everywhere"? Or maybe it's time to revive the "One API to rule them all"?
I don't know about you, but donating $50/$100 to wxPython doesn't sound at all like a bad idea to me. 
I can spare the dough, and I know it's worth every penny (and more). The CD can bundle the latest version of wxPython and maybe some popular third-party open source/freeware tools and would of course be cross-platform. Heck, I don't even need the CD, but I'd still go for a t-shirt. I've read that Mozilla's #1 source of income is donations, and to me that sounds like this would at least bring in some resources.
Other things (of course, these are just ideas I'm throwing out):
- hold a lottery when donations reach a certain total to add an extra incentive; I vote for iPods, but then again, that might be because I want to upgrade mine.
- support contracts: Robin gets a group of consultants and forwards requests to them. A portion of the money goes to the consultant, the rest to wxPython;
- provide a block of advertising space on the front page of wxPython.org for projects that offer commercial licensing, including IDEs and such; for open source projects who don't have the money to foot the bill, they can just "go in the back and do the dishes", helping Robin out with some work he needs done from his TODO list.
- custom development: nuff said! In addition to doing specific client work, I'd actually come up with specific projects (like wxMediaPlayer, wxHTML2, wxDataViewControl, more pythonic whatever...) and have a "goal" in terms of the amount of money that must be donated for the project to be funded. Once the goal is met, the project is started and eventually delivered. This is an extension of the bounty system.
- provide a wxPython "PlusPack" for, say, $50 or so that installs the entire dev environment from scratch, including Python and editing tools like DialogBlocks and CodeEditor / Dr. Python. Also some nice tutorials, free icons, and sample/template apps, better than what you can get online. Just double-click to install, and boom, everything's ready to go! (Just like with MSVS, XCode, etc.)
- *get wxPython advertised* - in the short term, this takes resources, but believe it or not, this would eventually lead to more resources. Ever noticed how lots of people are talking about Mono, GTK, Qt, and it seems like almost always wx is left out of the discussions? We need to have more of a public presence. We've got a nice community, but it seems like other toolkits (many of which aren't even as good) simply get more "airtime" because people are getting the word out about them. While I disagree with some of Mozilla's strategies, their focus on getting the word out is a smart and important one. We also need to make a clear, PHB friendly argument as to why Java and .NET aren't the only options out there, and in addition, maybe get a boxed, retail product out along the lines of the PlusPack I mentioned earlier. We need to talk to businesses, because, well, they've got money.
Well, that's all I can come up with for the moment. Some of these ideas are at least good "tracer bullet" candidates, IMHO. I'll try to keep thinking about it but I figured it's probably good to just shoot these off so that we can get some back and forth going.
Thanks,
Kevin
On Oct 22, 2004, at 12:03 PM, Chris Barker wrote:
[snip]
> Also, I don't forsee every app using wxversion, but
only those that want to stay behind with a not-current release of wxPython.
well, I don't know that I'll know whether I need it to stay behind when I first run it. If I update it to keep up with wxPython versions, I'll change the line.
[snip - sorry, we're going to get bogged down by the very same issues that were discussed earlier]
Honestly, I'll probably put a wx.requires() line in every app I write, just like I put a python version number in every #! line.
And that's exactly why I think you and Robin aren't on the same page here. As he said above, he doesn't expect people to use it as you intend to here. He wants it only for those who want (need?) to stay-behind, as a crutch, so to speak, and my guess is that he expects it to be a temporary one at that. You seem to want to use it to create a managed environment on other users' machines.
So, I certainly think there's the potential for some users to use this feature all the time as a core component of their distribution strategy. If more than a few people do this, it could make life really difficult for wxPython users who just want to download a script and run it using the latest wxPython. As a result, I think the current approach has a real potential to introduce as many (if not more) problems than it solves. And there's the tracer bullet dilemna here - once we know whether or not it will really introduce problems, many users will already be using it.
As an end user of Python scripts, I find someone forcing the user to create a managed environment to be, IMHO, annoying. It's one thing to provide the information a user needs to create a managed environment, but it's another thing entirely to not even give the user a choice. Either provide a package that includes everything the user'll need and doesn't muck with how they've configured their own Python environment, or let them choose how to configure their environment themselves and suffer any potential consequences. But don't make the user scour the web for the exact version of components X, Y, and Z your app needs and then install and configure them - just so that they can run your app. (Which is, BTW, far more error prone and troublesome than just shipping me a bundled app!)
Kevin
On Oct 22, 2004, at 12:03 PM, Chris Barker wrote:
Kevin Ollivier wrote:
As an end user of Python scripts, I find someone forcing the user to create a managed environment to be, IMHO, annoying. It's one thing to provide the information a user needs to create a managed environment, but it's another thing entirely to not even give the user a choice. Either provide a package that includes everything the user'll need and doesn't muck with how they've configured their own Python environment, or let them choose how to configure their environment themselves and suffer any potential consequences. But don't make the user scour the web for the exact version of components X, Y, and Z your app needs and then install and configure them - just so that they can run your app. (Which is, BTW, far more error prone and troublesome than just shipping me a bundled app!)
The more I see of these discussions, the more I feel 'require' might too strong a concept.
'Recommend', 'prefer' or 'select' seem more appropriate - then it leaves it in the user's hands to ignore the application developer's recommendation if they choose to.
I'm more of an interested bystander wrt to wxPython at the moment, though - I'm neither actively developing or using any wxPython apps.
Cheers,
Nick.
On Oct 22, 2004, at 12:03 PM, Chris Barker wrote:
Nick Coghlan wrote:
Kevin Ollivier wrote:
The more I see of these discussions, the more I feel 'require' might too strong a concept.
'Recommend', 'prefer' or 'select' seem more appropriate - then it leaves it in the user's hands to ignore the application developer's recommendation if they choose to.
The wxversion module in the next daily will have 'require' renamed to 'select'. It will still raise an exception if the requested version is not found. You seem to imply that falling back to the default in that case might be a good option. Any other thoughts on that?
I've also added the following functions:
def checkInstalled(versions):
"""
Check if there is a version of wxPython installed that matches one
of the versions given. Returns True if so, False if not. This
can be used to determine if calling `select` will succeed or not.
:param version: Same as in `select`, either a string or a list
of strings specifying the version(s) to check
for.
"""
def getInstalled():
"""
Returns a list of strings representing the installed wxPython
versions that are found on the system.
"""
I've given some thought to adding a 'checkUsing' function that can be used to test if the version currently imported matches some given criteria as Chris suggested, but I havn't started any work on it. Suggestions are welcome.
I'm also in the middle of some work on http://wiki.wxpython.org/index.cgi/MultiVersionInstalls to help clairify things better.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
I definitely think it should fall back to the default installation, perhaps popping up a wxMessageBox saying that you're running against a version other than the recommended version so there may be problems. (Perhaps also opening a browser window with the wxPython downloads page if the person says they want to install the proper version.) This gives the user a choice: install the wxPython version requested, or try it as is. As long as it's the user, not the developer, that makes the decision, then I'm okay with it.
Thanks,
Kevin
On Oct 23, 2004, at 1:14 PM, Robin Dunn wrote:
Nick Coghlan wrote:
Kevin Ollivier wrote:
The more I see of these discussions, the more I feel 'require' might too strong a concept.
'Recommend', 'prefer' or 'select' seem more appropriate - then it leaves it in the user's hands to ignore the application developer's recommendation if they choose to.The wxversion module in the next daily will have 'require' renamed to 'select'. It will still raise an exception if the requested version is not found. You seem to imply that falling back to the default in that case might be a good option. Any other thoughts on that?
Kevin Ollivier wrote:
Nick Coghlan wrote:
Kevin Ollivier wrote:
The more I see of these discussions, the more I feel 'require' might too strong a concept.
'Recommend', 'prefer' or 'select' seem more appropriate - then it leaves it in the user's hands to ignore the application developer's recommendation if they choose to.The wxversion module in the next daily will have 'require' renamed to 'select'. It will still raise an exception if the requested version is not found. You seem to imply that falling back to the default in that case might be a good option. Any other thoughts on that?
I definitely think it should fall back to the default installation, perhaps popping up a wxMessageBox saying that you're running against a version other than the recommended version so there may be problems. (Perhaps also opening a browser window with the wxPython downloads page if the person says they want to install the proper version.) This gives the user a choice: install the wxPython version requested, or try it as is. As long as it's the user, not the developer, that makes the decision, then I'm okay with it.
Not a bad idea. I'll look into that on Monday.
On Oct 23, 2004, at 1:14 PM, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Robin Dunn wrote:
The wxversion module in the next daily will have 'require' renamed to 'select'. It will still raise an exception if the requested version is not found. You seem to imply that falling back to the default in that case might be a good option. Any other thoughts on that?
I like Kevin's idea (with the standard behaviour provided by select being to display a warning dialog, with the option to continue with the default version or go download the specified version). For a lot of simple applications choosing to continue should work quite happily - but the user does need to know they're running a technically unsupported configuration.
However, could that dialog actually be displayed properly, given the wx.App won't have been created at this point? (I've never tried to work out what you can get away with before creating the App object)
The new functions (i.e. checkInstalled()) can be used any time an application developer wants to customise the handling of the case where the installed version differs from the expected version, so select() itself doesn't need to cope with that.
Cheers,
Nick.
Kevin Ollivier wrote:
On Oct 22, 2004, at 12:03 PM, Chris Barker wrote: [snip - sorry,
we're going to get bogged down by the very same issues that were
discussed earlier]
well, yes. let's not do that. But I do think there is a need for more
clarity of the issues. I'm still not sure where you stand:
Do you think there should be no wx.select at all? Or that it should only
select "major" versions? or ???
I do know you strongly support a better defined, and stronger, system
for maintaining backward compatibility among "minor" version upgrades.
I think we're all for that, provided it doesn't bog down improvements
too much. Of course, it's the "too much" that it is hard to agree on!
Honestly, I'll probably put a wx.requires() line in every app I
write, just like I put a python version number in every #! line.And that's exactly why I think you and Robin aren't on the same page
here.
Could be. That's why I'm trying to clarify things now. I don't thin it's
all that clear to any of us how this new feature will be used, and as
you said, the earlier we find that out the better, because before too
long, the cat will be out of the bag (to add more animal metaphors)
As he said above, he doesn't expect people to use it as you intend to
here. He wants it only for those who want (need?) to stay-behind, as
a crutch, so to speak, and my guess is that he expects it to be a temporary one at that.
I guess I'm not sure how one ever knows if you need to stay behind or
not. All I ever know is that what I have now works with the version(s)
I've tested it on. If I install it on my, or another person's, machine,
I don't want it to break when a newer version of wxPython is installed.
I can't know if the newer version will break it until it comes out, and
then it's too late to change something already installed.
I do certainly intend to keep any apps I'm maintaining up to date with
current versions.
You seem to want to use it to create a managed environment on other
users' machines.
Exactly, that's one very important use for me.
So, I certainly think there's the potential for some users to use
this feature all the time as a core component of their distribution
strategy.
I know I will.
If more than a few people do this, it could make life really
difficult for wxPython users who just want to download a script and
run it using the latest wxPython.
Here's were we disagree. Which is better:
1) User downloads an script, when it's run, it returns with an error:
"Can't find wxPython2.5.8, which is required for this script"
(or some other helpful message)
or
2) user downloads a script, tries to run it, and it starts up just fine,
then crashes when the mouse is clicked, with an error like:
TypeError: DC_DrawBitmap() takes at most 4 arguments (5 given)
I'd say the first one is much preferred. It is completely clear what the
problem is. While it may be annoying that they now have to either go get
another version of wxPython, or change the "select" line and test it,
that's better than an error from some place deep in the code that just
makes it look like you've given them a buggy piece of software.
For any code I'm giving to the world, I'll probably put the select()
call inside a try block, and give the user a useful message about what
version's I've tested on, and what they should do it they want to test
on a different version, but they should know that they are using an
untested version.
Again, I think if you are distributing to completely naive users, you
should either bundle it, or provide the run time environment for them anyway.
As a result, I think the current approach has a real potential to
introduce as many (if not more) problems than it solves.
I really don't see it as more problems, just making really clear what
the problems are. One point might be that the existence of this system
provides incentive for:
A) Robin to not make much effort at cross-version compatibility
B) Keeping developers (wxPython users) from bothering to test across
versions
This is true , but I think we can count on some discipline in these issues.
And there's the tracer bullet dilemna here - once we know whether or
not it will really introduce problems, many users will already be
using it.
True, but how can we figure this out without testing it?
As an end user of Python scripts, I find someone forcing the user to
create a managed environment
I'm not suggesting forcing anything. The *.py file is being distributed
here. All you need to do is comment out the select() line!
to be, IMHO, annoying. It's one thing to provide the information a
user needs to create a managed environment, but it's another thing
entirely to not even give the user a choice.
Either provide a package that includes everything the user'll need
and doesn't muck with how they've configured their own Python
environment, or let them choose how to configure their environment
themselves and suffer any potential consequences.
How the heck hard is it to comment out one "select()" line at the top of
a script? Any user that can't do that should get a bundle or run-time
environment. I really think you're concerned about a very narrow group of
users: not knowledgeable enough to comment out a line, but knowledgeable
enough to "choose how to configure their environment themselves". Also
knowledgeable enough to not get pissed off when the app crashes due to a
version incompatibility, with no message indicating that this is a problem.
Any number of READMEs that say "this was only tested with the following
versions of wxPython" is less effective than something explicit in the
code, and an error message (or warning) when run.
But don't make the user scour the web for the exact version of
components X, Y, and Z your app needs and then install and configure
them - just so that they can run your app. (Which is, BTW, far more
error prone and troublesome than just shipping me a bundled app!)
I agree, you should either provide a bundles app, or provide and
installer for components X, Y, and Z. That is, if you're trying to
support your users.
I definitely think it should fall back to the default installation,
perhaps popping up a wxMessageBox saying that you're running against
a version other than the recommended version so there may be
problems. (Perhaps also opening a browser window with the wxPython
downloads page if the person says they want to install the proper
version.) This gives the user a choice: install the wxPython version
requested, or try it as is. As long as it's the user, not the
developer, that makes the decision, then I'm okay with it.
Okay, I like this too. As long as the tested version is specified in the code, and the user knows they are running with an untested version, I'm okay with that too. Hey maybe all this jabbering has actually resulted in a consensus we all like!
Anyway, I still think it's useful for us to write down our suspected use
cases, so we can get an idea of how we think this is going to be used,
and decide if:
--the approach supports the uses we envision
--We think the uses are a good idea, or will "introduce more problems
than they solve"
I'll repeat what I wrote before, I hope other will add/comment:
1) folks on wxPython-dev:
We want to be able to run various versions, and have them all installed
at once. wx.require() is a great way to handle this. On the other hand,
we're also sophisticated enough to develop and use our own schemes for
switching between versions.
2) end users, who may not even know their app is written in Python:
These folks should be given a package built with Py2exe Py2app, or
whatever, and this is a non-issue there too.
3) wxPython programmers:
These are folks that are using wxPython, but not involved in it's
development. They have less need to run multiple versions, but they
still have some need. They nay have apps and utilities already written
that they don't want to change when they upgrade, they may see examples
in the Wiki that use a different version than they are using, etc.
wx.require would be very helpful to these folks.
4) Managed users:
These are folks that will run various wxPython based programs on their
machines. They haven't written them themselves, but will use them , and
have newer ones installed later. The programs and the wxPython
installers will have be provided to them. This is a group I am
targeting. Folks in my organization that I give small utilities to. I
don't mind having to give them a new wxPython installer when I give them
a new app that requires and updated version, but I want the stuff I gave
them last year to still work also.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
Nick Coghlan wrote:
Robin Dunn wrote:
The wxversion module in the next daily will have 'require' renamed to 'select'. It will still raise an exception if the requested version is not found. You seem to imply that falling back to the default in that case might be a good option. Any other thoughts on that?
I like Kevin's idea (with the standard behaviour provided by select being to display a warning dialog, with the option to continue with the default version or go download the specified version). For a lot of simple applications choosing to continue should work quite happily - but the user does need to know they're running a technically unsupported configuration.
However, could that dialog actually be displayed properly, given the wx.App won't have been created at this point? (I've never tried to work out what you can get away with before creating the App object)
The new functions (i.e. checkInstalled()) can be used any time an application developer wants to customise the handling of the case where the installed version differs from the expected version, so select() itself doesn't need to cope with that.
I think I've come to the same conclusion. The select function could
easily create an App object for itself in order to create and display
the dialog, but then the best thing to do after that is to exit instead
of letting the application continue with the default wx, because it will
end up making a new App object, which can cause problems.
So I think I will put some recommended usage examples in the module
docstring and the wiki that show how to check for the version and give a
warning, etc.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Hi Robin and all,
Nick Coghlan wrote:
Robin Dunn wrote:
The wxversion module in the next daily will have 'require' renamed to 'select'. It will still raise an exception if the requested version is not found. You seem to imply that falling back to the default in that case might be a good option. Any other thoughts on that?
I like Kevin's idea (with the standard behaviour provided by select being to display a warning dialog, with the option to continue with the default version or go download the specified version). For a lot of simple applications choosing to continue should work quite happily - but the user does need to know they're running a technically unsupported configuration.
However, could that dialog actually be displayed properly, given the wx.App won't have been created at this point? (I've never tried to work out what you can get away with before creating the App object)
The new functions (i.e. checkInstalled()) can be used any time an application developer wants to customise the handling of the case where the installed version differs from the expected version, so select() itself doesn't need to cope with that.I think I've come to the same conclusion. The select function could
easily create an App object for itself in order to create and display
the dialog, but then the best thing to do after that is to exit instead
of letting the application continue with the default wx, because it will
end up making a new App object, which can cause problems.So I think I will put some recommended usage examples in the module
docstring and the wiki that show how to check for the version and give a
warning, etc.
Thinking about this more, I think maybe what we need in addition to the checkInstalled(), etc. is a wxversion.minimal(minversion) function for apps that won't run with a version < minversion. In *that* case, we could pop up the upgrade window and then bomb out with no worries. And if an upgrade is required to run the script, I don't see why we shouldn't do this.
Otherwise, I agree with what you guys said about just having the app decide what to do. In fact, I like that whole strategy better since wxversion basically becomes an information provider that gives the developer the info s/he needs to handle versioning issues, but leaves the decision up to the developer. It just seems like a more natural way of handling things to me.
Thanks,
Kevin
On Oct 25, 2004, at 12:01 PM, Robin Dunn wrote:
Kevin Ollivier wrote:
So I think I will put some recommended usage examples in the module
docstring and the wiki that show how to check for the version and give a
warning, etc.
I've put some examples in section 1.4 here: http://wiki.wxpython.org/index.cgi/MultiVersionInstalls
Thinking about this more, I think maybe what we need in addition to the checkInstalled(), etc. is a wxversion.minimal(minversion) function for apps that won't run with a version < minversion. In *that* case, we could pop up the upgrade window and then bomb out with no worries.
Ok. Should it have a preference for the version given or should it choose the largest version number greater than minversion? (I think the latter, but I can see a case for the former too.) What about an upper bound, perhaps selectFromRange(minVersion, maxVersion=None) ?
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Kevin Ollivier wrote:
So I think I will put some recommended usage examples in the module
docstring and the wiki that show how to check for the version and give a
warning, etc.I've put some examples in section 1.4 here: http://wiki.wxpython.org/index.cgi/MultiVersionInstalls
Thanks! I've done a basic read through and it looks good. I'll probably review again later to try and catch anything I might've missed.
Thinking about this more, I think maybe what we need in addition to the checkInstalled(), etc. is a wxversion.minimal(minversion) function for apps that won't run with a version < minversion. In *that* case, we could pop up the upgrade window and then bomb out with no worries.
Ok. Should it have a preference for the version given or should it choose the largest version number greater than minversion? (I think the latter, but I can see a case for the former too.)
I think it should choose the largest version number installed. Actually the use case that made me think of this was Chris Barker's statement about using wxversion in wiki scripts. I thought wxversion.select('2.4') scripts probably need to be taken out of the wiki or updated, but I think it is sensible to have an indicator of a "minimal" version for wiki scripts (or any scripts on the web for that matter). This way achieves a balance between "human readable" errors when the script obviously can't run, while still encouraging testing of new versions where it *should* run.
What about an upper bound, perhaps selectFromRange(minVersion, maxVersion=None) ?
I'd prefer that people write their own scripts to do stuff like this. If a lot of people do it, we could add it to wxversion in the future, but I think we should let users take initiative if they want advanced features like this. Basically, my opinion is that I don't want to make it easy to discourage testing on a new version, and I think the current wxversion achieves a nice balance between giving people the tools they need to write scripts like this (if it's really needed), while not making it so simple to do that people will use it just as a quick and dirty way out of testing. (Again, that's a prime use case for bundling in my eyes.)
Thanks,
Kevin
On Oct 26, 2004, at 10:36 AM, Robin Dunn wrote: