![]() ![]() I'd also note that Ned Deily (who has been managing the builds for ) is sympathetic - I imagine he'd help out if someone gives it a try. There is actually no reason that the pythonw executable has to be part of a framework build - those two things are orthogonal, but separating them out will require some build script hacking. The framework builds included the pythonw executable hack. In addition, the Framework builds were set to build "fat" binaries (32+64 bit) - not sure if that's still the case, but it was a complication. plain old *nix builds (what conda is using now)Ģ)"framework" builds - which put all of python inside ans OS-X Framework.NOTE: the challenge for updateing the feedstock is that the build scripts are only set up to do particular build combinations (or were, I haven't looked in a while): Update the recipe for os-x to build the pythonw.exe.ĭo a PR to the feedstock, and see what happens. So, if you have the inclination (and time), I would: ![]() I think the core problem is that no one has been motivated enough to do the work.Ĭonda-forge is a way to get new packages out to users, and also a potential route to getting something different into defaults - once porven useful, there is at least a chance of that. !searchin/anaconda/why$20not$20make$20python$20invoke$20the$20framework/anaconda/-ZAynUQW5HQ/6g4_4v96S_cJĪs kludgy as it is, the bootstrap executable looks quite usable. This technical details have been discussed some on the Anaconda list: Note: if you search the Anaconda list for pythonw, you see this has created a lot of issues and confusion - maybe most have been solved with a one-character change to a #! line, but it would have been better not to have it at all, yes? Whether you use the current shell script re-direct or python,org's executable, I have no opinion on - whatever works is fine, but it really would make it easier to use Anaconda on OS-X. I suggest that Anaconda do the same thing - it would really make things easier for GUI develoment, testing, using MPL with some back-ends, etc, etc, etc. And the build has been shipping that way for years, with apparently no complaints from anyone. As far as I can tell, this provides no downside of any sort for command line apps, and makes the whole GUI thing a lot easier to deal with. The builds solved this many releases ago - they have a small bianry executable that re-directs to a properly set up python - and this is the default, so "python" and "pythonw" do exactly the same thing. ![]() And going in an hacking nosetests does not seem like the way to solve this (and is less then trivial, actually, I just spent some time trying to figure it out, to no avail) the whole test process fails, as nose is not being run with the right python. It's not SUCH a big deal to type pythonw when you need to run a GUI app, nor is it that bad to change the #! line on scripts (though that makes it all less system independent - does linux even HAVE a pythonw in general?īut when this really kills me is when I'm not controlling the start-up script - in particular, I'm using nose to run tests, some of which require wxPython to be started up. In short, our mission is to bring programming for the 99%.On OS-X, for a process to access the windowing system the executable must be in a "Framework" or an "Application bundle" or somethign or other.Īnaconda addresses this by providing a "pythonw" command that is a shell script that re-directs itself to start up a copy of python that is inside a provided *.app bundle.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |