Re: [pygame] PyGame Runtime
In a message of Mon, 07 May 2007 22:22:45 EDT, Ethan Glasser-Camp writes: Do we want to try to undercut Flash? If so, what we need to do is start thinking about how to effectively sandbox Python (widely accepted as impossible?) and get pygame apps to run in the browser (deep magic?). I'm not sure this is a worthy goal for us in any case -- it certainly doesn't excite me personally. Ethan If you want to sandbox python, you might want to start with PyPy. Start reading about the Taint Object space here. http://codespeak.net/pypy/dist/pypy/doc/objspace-proxies.html Laura
Re: [pygame] PyGame Runtime
On Tue, May 08, 2007 at 11:45:13AM +1000, Cameron Blackwood wrote: Hi, long time reader, first time caller... (well ok, second time :) James Paige writes: | | On Tue, 8 May 2007, James Paige wrote: | | When packaging for Linux, you should NOT be trying to bundle in a copy | of python and pygame and all other dependencies. You should instead use | a packaging format which simply describes the packages/versions that it | depends on. The package manager handles the rest. To james I say. Ive had nightmares with rpm's and even a couple of problems with ebuilds. You download 26M of ogre/pyogre only to find you need to forward your version of libfoo.rpm. Oh, but that breaks your appbar.rpm. Oh and I need to upgrade my glibc.rpm. Again. :-/ Frankly, getting dependany stuff sorted for pyweek is a nightmare (even under gentoo, gentoo often rolls their packages forward too quickly so older, slower to update libraries have dependancy stuff that isnt around in portage any more). For linux, people seem to 'chase' the 100% latest version of some of these libraries, which is ok for slowly changing ones, but it sucks for ones that have a version a week. Windows doesnt have the dependancy problem that linux has (or the constant version increases) but unless you have a compiler you're stuck with the packages that you can _find_, which arnt always easily available. *cough* pygame-1.8 */cough* :) Getting ogre and some of the bigger libraries compiled on linux is, and Ill be nice here, not exactly easy. Oh and I work as a linux sysadmin. Yes I could have sat there for hours and worked it out, but you know, to tryout/run _one_ pyweek entry, it really wasnt worth it. (And before you ask, this was on a gentoo system... it didnt complain about dependancy errors, it just failed to build 1/2 way through. Yay!) Interesting. I used to use RPMs on Redhat back in the 1999-2001 range, but I gave it up because of dependency hell-- I had simply assumed that the Fedora Project had solved those problems since then. I have been using Debian and/or Ubuntu ever since. .deb based packaging systems are always really good about keeping old versions of libraries available... I'm having a hard time thinking of a single instance of dependency problems in my entire .deb experience that didn't involve a manually-installed program... Perhaps I was mistaken to say that .rpm and .ebuild are just as good as .deb... --- James Paige
Re: [pygame] PyGame Runtime
Cameron Blackwood wrote: Yes, you'd be lagging the 'latest features' of most of the game libraries, but I always hate having to grab _yesterdays_ version of libfoo anyway. This wouldn't be so much of a problem if it could be designed to hold multiple versions of libraries, with the game specifying which versions it wants to use. Then newer versions of libraries could be added to the runtime to support newer games without breaking older ones. -- Greg
Re: [pygame] PyGame Runtime
On Mon, May 07, 2007 at 01:50:03PM +1200, Greg Ewing wrote: Nathan wrote: is there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) Someone needs to get all the Linux distributors, bang their heads together and make them come up with a single packaging system that works on all distributions. Okay, I gotta step in here. Non-linux users should stop trying to impose a windows-style installation scheme on Linux users. rpm's debs' and ebuilds are all great systems. All three of them do something really tremendously important that windows/mac users often fail to understand-- they handle dependencies. When packaging for Linux, you should NOT be trying to bundle in a copy of python and pygame and all other dependencies. You should instead use a packaging format which simply describes the packages/versions that it depends on. The package manager handles the rest. Response to common complaint #1: But I don't want to make 3+ different types of package for Linux! Too much work: Make a tarball of your source code. Let someone else do the packaging. There are gentoo users who LOVE writing ebuilds. there are debian users who LOVE packaging debs. Just give them the tarball, and let them go to town. Response to common complaint #2: But I want it to be so easy that grandma can install it: Grandma will be running Ubuntu Linux. Her grandson will have enabled the Multiverse repository and put a shortcut to synaptic on her desktop. She'll find your game in the Games category. Her installation experience will be even easier than the grandma who is running XP. Response to common complaint #3: But I simply can't accept the idea that Linux users would want something different than what I am used to! Windows-style installers for Linux are not hard to make. Links to tools for making them have already been posted (in this thread!). If you insist on this kind of installer (or are making a closed-source game), you can do it already. /rant --- James Paige
Re: [pygame] PyGame Runtime
RE: James Paige Amen brother!
Re: [pygame] PyGame Runtime
On 5/6/07, Greg Ewing [EMAIL PROTECTED] wrote: Will McGugan wrote: I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle So maybe what we want is an extension of py2exe that not only creates an executable but an installer as well? That would be nice. Once I took the time to get py2exe working, I didn't want to invest the time to even figure out the installer step for windows -- since I don't even use windows myself. ~ Nathan
Re: [pygame] PyGame Runtime
On Tue, 8 May 2007, James Paige wrote: Okay, I gotta step in here. Non-linux users should stop trying to impose a windows-style installation scheme on Linux users. rpm's debs' and ebuilds are all great systems. All three of them do something really tremendously important that windows/mac users often fail to understand-- they handle dependencies. When packaging for Linux, you should NOT be trying to bundle in a copy of python and pygame and all other dependencies. You should instead use a packaging format which simply describes the packages/versions that it depends on. The package manager handles the rest. Without wanting to be too rude about it, I have to say that's an interesting fantasy world you live in there :) 1. while I'd like to believe that we'll magically get packages for all the games produced by PyWeek I know it's never going to happen. 2. you'll never, ever get the library version sets correct. One game will require library X version 1.1.1, another version 1.1.2 (assume there's binary incompatibility between the two ;). You can't expect Linux distributions to maintain so many library versions, or cope with them all being installed. This means there's no single dependency that can satisfy all game's requirement for library X. 3. I'm speaking as a happy Ubuntu user here, but even synaptic etc. on Ubuntu can't hold a candle to the drag-n-drop installation of applications under OS X. Richard
Re: [pygame] PyGame Runtime
On Tue, May 08, 2007 at 08:20:20AM +1000, Richard Jones wrote: On Tue, 8 May 2007, James Paige wrote: Okay, I gotta step in here. Non-linux users should stop trying to impose a windows-style installation scheme on Linux users. rpm's debs' and ebuilds are all great systems. All three of them do something really tremendously important that windows/mac users often fail to understand-- they handle dependencies. When packaging for Linux, you should NOT be trying to bundle in a copy of python and pygame and all other dependencies. You should instead use a packaging format which simply describes the packages/versions that it depends on. The package manager handles the rest. Without wanting to be too rude about it, I have to say that's an interesting fantasy world you live in there :) 1. while I'd like to believe that we'll magically get packages for all the games produced by PyWeek I know it's never going to happen. Okay, I am exaggerating, but I honestly have had strangers mail me and say Hey! I am making an ebuild for you! Is that okay? Your mileage may vary. I'll bet you a dollar that both the winners of the recent pyweek (Barbie Seahorse Adventures and Which way is up?) will be in Ubuntu multiverse before 2 months have passed (and to make if fair, the packaging has to be done by someone who isn't me :) 2. you'll never, ever get the library version sets correct. One game will require library X version 1.1.1, another version 1.1.2 (assume there's binary incompatibility between the two ;). You can't expect Linux distributions to maintain so many library versions, or cope with them all being installed. This means there's no single dependency that can satisfy all game's requirement for library X. I disagree-- every pygame game I try works for me out-of-the-box without worrying about versions. I haven't encountered a pygame game yet that required a library or library-version that wasn't readily available to me. 3. I'm speaking as a happy Ubuntu user here, but even synaptic etc. on Ubuntu can't hold a candle to the drag-n-drop installation of applications under OS X. The mac drag-and-drop app installation thing is nice-- and I admit I would prefer it as an alternative to windows-style installers if it were available on linux --- James I'm Totally Good For That Dollar Paige
Re: [pygame] PyGame Runtime
I don't know.. The drag and drop thing is nice and all, but it's pretty damn easy just to search for what you want in Synaptic, mark it, and click apply. . The whole central repository thing has advantages as well. What are the chances of getting malware from it ? It has to go through a screening process to become available in the repository. Not saying that it is impossible for baddies to get in there, but pretty darn difficult. . There is also nothing stopping a group of enterprising individuals from creating their own gaming repository. complete with all various versions of libraries, that might not be included in the main distro repo. but isn't it much easier to target your game to work on the more popular distros and submit them for inclusion there ? You could worry whether your game works for kitten linux light, but why ? If there are users that want it, someone will build it for them. . Distribution through repositories is the best way. Unknown .exe's for download is why Windows users have the problems they do. Personaly, I don't want to get my software direct. If it's in the repository I know it's been through some screening and testing. This is not to say I wouldn't get some source code direct from someone who already has submissions in a repo. My level of trust would be greater from them I guess. . Just my 2 cents. Dennis --- On Mon 05/07, Richard Jones [EMAIL PROTECTED] wrote: From: Richard Jones [mailto: [EMAIL PROTECTED] To: pygame-users@seul.org Date: Tue, 8 May 2007 08:20:20 +1000 Subject: Re: [pygame] PyGame Runtime On Tue, 8 May 2007, James Paige wrote: Okay, I gotta step in here. Non-linux users should stop trying to impose a windows-style installation scheme on Linux users. rpm's debs' and ebuilds are all great systems. All three of them do something really tremendously important that windows/mac users often fail to understand-- they handle dependencies. When packaging for Linux, you should NOT be trying to bundle in a copy of python and pygame and all other dependencies. You should instead use a packaging format which simply describes the packages/versions that it depends on. The package manager handles the rest.Without wanting to be too rude about it, I have to say that's an interesting fantasy world you live in there :)1. while I'd like to believe that we'll magically get packages for all the games produced by PyWeek I know it's never going to happen.2. you'll never, ever get the library version sets correct. One game will require library X version 1.1.1, another version 1.1.2 (assume there's binary incompatibility between the two ;). You can't expect Linux distributions to maintain so many library versions, or cope with them all being installed. This means there's no single dependency that can satisfy all game's requirement for library X.3. I'm speaking as a happy Ubuntu user here, but even synaptic etc. on Ubuntu can't hold a candle to the drag-n-drop installation of applications under OS X. Richard ___ Join Excite! - http://www.excite.com The most personalized portal on the Web!
Re: [pygame] PyGame Runtime
Hi, long time reader, first time caller... (well ok, second time :) James Paige writes: | | On Tue, 8 May 2007, James Paige wrote: | | When packaging for Linux, you should NOT be trying to bundle in a copy | of python and pygame and all other dependencies. You should instead use | a packaging format which simply describes the packages/versions that it | depends on. The package manager handles the rest. To james I say. Ive had nightmares with rpm's and even a couple of problems with ebuilds. You download 26M of ogre/pyogre only to find you need to forward your version of libfoo.rpm. Oh, but that breaks your appbar.rpm. Oh and I need to upgrade my glibc.rpm. Again. :-/ Frankly, getting dependany stuff sorted for pyweek is a nightmare (even under gentoo, gentoo often rolls their packages forward too quickly so older, slower to update libraries have dependancy stuff that isnt around in portage any more). For linux, people seem to 'chase' the 100% latest version of some of these libraries, which is ok for slowly changing ones, but it sucks for ones that have a version a week. Windows doesnt have the dependancy problem that linux has (or the constant version increases) but unless you have a compiler you're stuck with the packages that you can _find_, which arnt always easily available. *cough* pygame-1.8 */cough* :) Getting ogre and some of the bigger libraries compiled on linux is, and Ill be nice here, not exactly easy. Oh and I work as a linux sysadmin. Yes I could have sat there for hours and worked it out, but you know, to tryout/run _one_ pyweek entry, it really wasnt worth it. (And before you ask, this was on a gentoo system... it didnt complain about dependancy errors, it just failed to build 1/2 way through. Yay!) | On Tue, May 08, 2007 at 08:20:20AM +1000, Richard Jones wrote: | | Without wanting to be too rude about it, I have to say that's an interest | ing | fantasy world you live in there :) | | 1. while I'd like to believe that we'll magically get packages for all th | e | games produced by PyWeek I know it's never going to happen. To richard I say How about if you build it, they will come? If someone _did_ gather and build a 100% stand alone python + pygame + opengl + openal + ogre + etc 'tree' for windows, mac and linux then I think you'd find that a lot of people would start to use it in preference to the current 'roll your own/install lots of packages' system. Personally, I wouldnt make it a package at all. If you just made it a just directory zip/tar of a 100% self sustained python+everything (and a setup program to patch the paths and finish the install) then anyone could use it, anywhere, on anything and _know_ that stuff would work ok. No dependancy hell, no more downloading libfoo-1.2.3 too. If you finish with it, just 'nuke' the tree (no registry hell, no package tracking). That would make creating 'game cd's very easy too. You could make it kind of 'drag and drop' too /foo/bar/gamepython/ gamepython/ python -- binary libs/ -- all the libs etc games/ game_picker[.exe/py] --- simple 'games chooser' app Just drop/extract games into '/gamepython/games' and you're away. (You know where python is in relative to that directory so your game can work it out the path easily, or maybe you can have a default sh/bat file that walks back looking for gamepython/python in each game's directory.) You'd have a 'universal' python game environment. (Yes, you'd be lagging the 'latest features' of most of the game libraries, but I always hate having to grab _yesterdays_ version of libfoo anyway. Id trade features for universal pretty well any day). You may still have glibc problems for linux, but really, stuffing round with ldpath/static binaries/including all of glibc (remember 100% self sustained install) would probably get around that. To me, that would be a pretty attractive draw win/os/mac... no other installing... easy stand alone distribution/CD creation. Ah, Im in lurve. Im going to stop dreaming now... :) cheers, cam :-) -- / `Rev Dr' cam at darkqueen.orgRoleplaying, virtual goth \ http://darkqueen.orgPoly, *nix, Python, C/C++, genetics, ATM \ [+61 3] 9809 1523[h] skeptic, Evil GM(tm). Sysadmin for hire / -- Random Quote -- Son, someday a man is going to walk up to you with a deck of cards on which the seal is not yet broken. And he is going to offer to bet you that he can make the Ace of Spades jump out of the deck and squirt cider in your ears. But son, do not bet this man, for you will end up with a ear full of cider. -- Sky Masterson's Father
Re: [pygame] PyGame Runtime
Cameron Blackwood wrote: How about if you build it, they will come? If someone _did_ gather and build a 100% stand alone python + pygame + opengl + openal + ogre + etc 'tree' for windows, mac and linux then I think you'd find that a lot of people would start to use it in preference to the current 'roll your own/install lots of packages' system. No dependancy hell, no more downloading libfoo-1.2.3 too. If you finish with it, just 'nuke' the tree (no registry hell, no package tracking). That would make creating 'game cd's very easy too. Don't you still have dependency hell with this system? i.e. I write a game with features in today's Ogre, and it's not in the tree (repository), so the suer has to retrieve it and build it separately. If I got to pick one impossible dream to fulfill, I would definitely prefer dbcad's solution of a standalone apt repo which is dedicated to maintaining builds of whatever versions of whatever libraries are needed. For PyWeek games, you can probably guess that most of them are built using fairly similar versions of the above tools. I think in the ultra-casual market, Pygame is going to forever lose to Flash. Flash games run straight from the browser with no download. I don't think we can beat that, at least not with a technology like the one proposed by Will McGugan. Do we want to try to undercut Flash? If so, what we need to do is start thinking about how to effectively sandbox Python (widely accepted as impossible?) and get pygame apps to run in the browser (deep magic?). I'm not sure this is a worthy goal for us in any case -- it certainly doesn't excite me personally. Ethan signature.asc Description: OpenPGP digital signature
RE: [pygame] PyGame Runtime
Ethan Glasser-Camp wrote: I think in the ultra-casual market, Pygame is going to forever lose to Flash. Flash games run straight from the browser with no download. I don't think we can beat that, at least not with a technology like the one proposed by Will McGugan. Do we want to try to undercut Flash? If so, what we need to do is start thinking about how to effectively sandbox Python (widely accepted as impossible?) and get pygame apps to run in the browser (deep magic?). I'm not sure this is a worthy goal for us in any case -- it certainly doesn't excite me personally. Ethan Isn't this what silverlight (http://www.microsoft.com/silverlight/) is promising? Graphics heavy clients, in browser, python (among others) langauage scripting. And there's some hope that mono will jump on board for cross-platform support. - John Krukoff [EMAIL PROTECTED]
Re: [pygame] PyGame Runtime
On 5/7/07, Ethan Glasser-Camp [EMAIL PROTECTED] wrote: I think in the ultra-casual market, Pygame is going to forever lose to Flash. Flash games run straight from the browser with no download. I don't think we can beat that, at least not with a technology like the one proposed by Will McGugan. Do we want to try to undercut Flash? If so, what we need to do is start thinking about how to effectively sandbox Python (widely accepted as impossible?) and get pygame apps to run in the browser (deep magic?). I'm not sure this is a worthy goal for us in any case -- it certainly doesn't excite me personally. Actually when it comes to money in the PC games market, flash games in the browser don't make nearly as much as downloadable titles. People often make downloadable binaries out of flash though, cause it is a great environment to make professional games.
Re: [pygame] PyGame Runtime
Will, first off I think it's wonderful that you're thinking so much of distribution. When it comes to the majorty of the downloadable game audience (the less technical part) I think having reasonable end-user distribution is a pre-requisite to the success of any game generation tool chain. To put another way, if a good distribution option was not there for tool x, distribution would have a signficantly increased failure rate, and the majority of game developers in the world would take tool x off of their list. However with your idea of a Pygame Runtime, I honestly think it would be a large step backwards, at least for the Mac and Win markets. The big reason why I say that is because the number one issue for distribution to be successful to the mass downloadable market is that when they find and run your link, it all just works. Basically most people will not put any work at all into figuring out why they can't run what they downloaded. They'll just go find and play one of the thousands of games that do just work. Also no distribution channel for downloadable games will take a game for inclusion if it doesn't just work for the vast majority of users. If there is a dependency that is required and not included - any at all - then it won't work for people without the dependency. And a runtime (that is not included) is a dependency. Also, when mentioning py2exe you said it will generate a large bundle of files - and then you are left with the tedious task of making an installer.. I can see how those might look like a negative at first glance (having lots of files then writing an installer) - but in terms of the final output of that process, it's very well suited to the windows downloadable market. The market is well established with end-users knowing how to: a) download and run something b) launch a program from the start menu or desktop. The installer gives you a single file to run that installs start menu shortcuts. It's all set. What the contents of the install directory look like is basically irrelevant. Also writing and building an installer is actually really easy (easier than py2exe in my opinion), and is so short and simple it doesn't have time to be tedious. It's usually just filling out a little script file (like 10 or so lines) Inno Setup is really awesome for windows installers: http://www.jrsoftware.org/isinfo.php ... all that being said, the one way I can see the runtime idea really working, is if the runtime was also a game browsing and downloading client, and then the download link for a game in that system was basically just the client. WildTangent and Steam are basically like this. I still would perfer distributing installers myself (I like that it would be more open) but I would be interested in submiting content into a system like that, and I can see it being successful. On 5/6/07, Will McGugan [EMAIL PROTECTED] wrote: Just posted an entry about a suggested 'PyGame Runtime'. I'd love to hear the opinion of the PyGame community on this one! http://www.willmcgugan.com/2007/05/06/pygame-runtime/
Re: [pygame] PyGame Runtime
Brian Fisher wrote: Will, first off I think it's wonderful that you're thinking so much of distribution. When it comes to the majorty of the downloadable game audience (the less technical part) I think having reasonable end-user distribution is a pre-requisite to the success of any game generation tool chain. To put another way, if a good distribution option was not there for tool x, distribution would have a signficantly increased failure rate, and the majority of game developers in the world would take tool x off of their list. However with your idea of a Pygame Runtime, I honestly think it would be a large step backwards, at least for the Mac and Win markets. The big reason why I say that is because the number one issue for distribution to be successful to the mass downloadable market is that when they find and run your link, it all just works. Basically most people will not put any work at all into figuring out why they can't run what they downloaded. They'll just go find and play one of the thousands of games that do just work. Also no distribution channel for downloadable games will take a game for inclusion if it doesn't just work for the vast majority of users. If there is a dependency that is required and not included - any at all - then it won't work for people without the dependency. And a runtime (that is not included) is a dependency. Surely it is better than the current situation where there all these great games on pygame.org that are only ever played by other PyGame coders. Personally I wouldn't mind a runtime, but I'll grant you that a lot of potential end users would baulk at having to download an extra dependancy - and we can't foist it on them like Microsoft. I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle unless they have something particularly impressive that they want to distribute. It is also more of a hassle if you want the game to run on multiple platforms. A runtime wouldn't preclude creating your own install package, coders would be free to chose one or both methods of distribution. How about a compromise where the game is attached to a small stub exe that checks for the presence of the runtime, and offers to download it if it isn't present? Although that does kind of defeat the cross-platform benefit. Will
Re: [pygame] PyGame Runtime
On 5/6/07, Will McGugan [EMAIL PROTECTED] wrote: [Runtime is step backwards] Surely it is better than the current situation where there all these great games on pygame.org that are only ever played by other PyGame coders. This assertion isn't continuing the argument - it's claiming some goal is good and presuming your proposal accomplishes that goal. I was arguing that the proposal wouldn't accomplish the goal you originally stated. In your blog you proposed a specific technical option for distribution in order to help pygame-based games launch it on the internet, and perhaps even profit from it. And in your last paragraph you implicitly suggested that your distribution proposal would make pygame-based games competitive in the Casual games market. My post was arguing that the distribution proposal you made (a seperate runtime install) wouldn't help significantly in getting pygame based games into the mass market hands on windows. I may have been a little extreme saying a runtime would be a step backwards, but my rationale in that is that if you've got some option that people are led to believe solves some problem, when it doesn't really solve that problem, then it's just distracting noise. And because there are already solutions that solve those problems (installers over packaged apps) it seems a step backwards, even if it does improve in other areas. Personally I wouldn't mind a runtime, but I'll grant you that a lot of potential end users would baulk at having to download an extra dependancy This comment seems to miss the point of what I was saying. It's not about minding a runtime, or people baulking at having to have an extra download. Most people won't mind the extra download either, even though they won't go do that extra download. It just comes down to that if things don't work, most people (in the downloadable market anyways) will not go figure out how to fix it. It just simply won't happen. In the PC downloadable market, you used to see this a lot with DirectX 9 vs. DirectX 8.1 (Win XP originally came with 8.1, although SP2 comes with 9.0). It killed distribution, so people determined to stick with 9.0 mitagated it with either included runtime installers and special windows with links to download and all that. That stuff worked pretty good, i.e. people didn't seem to mind the extra install terribly much But with a zip file renamed to an unrecognized extension? well you can't do any of that hand holding at all. It would ust look broken. And that would absolutely devastate your download to run rate on distribution. I'm talking taking it down by like 90+% I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle unless they have something particularly impressive that they want to distribute. It is also more of a hassle if you want the game to run on multiple platforms. I get the multiple platform thing, and I agree it would be great to be able to build a single package to work on all platforms - but I don't see the idea of a runtime being a great solution to the multiple platform thing. So does the runtime include pyOpenGL? Does it include pyOpenAL? The fmod wrapper the devs compiled themselves? the extension they wrote themselves? Lets say the runtime includes every extension you need - what about version of the runtime? If you need a newer python will the runtime auto update? If it does auto update, does it break the game that was tested only on 2.4? Basically how do you know the environment you tested on is the way it will run when distributed? Granted all of these problems can be solved with a runtime - but py2exe or py2app type approaches to packaging solve all these complexities well. A runtime wouldn't preclude creating your own install package, coders would be free to chose one or both methods of distribution. How about a compromise where the game is attached to a small stub exe that checks for the presence of the runtime, and offers to download it if it isn't present? Although that does kind of defeat the cross-platform benefit. That does sound like an improvement - but it is also a step in the direction of just packaging the whole thing as an executable with all it's dependencies in it.
Re: [pygame] PyGame Runtime
I agree with Brian. Slightly related to this topic: I've had good success with py2app and py2exe for OS X and Windows, respectively--is there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) ~ Nathan
Re: [pygame] PyGame Runtime
Source code in a tar ball, with a setup.py, and a ./configure make. You can make binaries too... but source is preferred. On 5/7/07, Nathan [EMAIL PROTECTED] wrote: I agree with Brian. Slightly related to this topic: I've had good success with py2app and py2exe for OS X and Windows, respectively--is there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) ~ Nathan
Re: [pygame] PyGame Runtime
On 5/6/07, Nathan [EMAIL PROTECTED] wrote: pis there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) people have previously posted about pyinstaller to this list, and it's web page says it can package as executables for linux (I've never used it myself): http://pyinstaller.python-hosting.com/
Re: [pygame] PyGame Runtime EGGS
I like it.. I don't know crap about jars (which is what they compared it to).. But it seems to me it would be better compared to APT. . APT solved a lot of these same problems in Linux. . Just my 2 cents Dennis --- On Sun 05/06, Laura Creighton [EMAIL PROTECTED] wrote: From: Laura Creighton [mailto: [EMAIL PROTECTED] To: pygame-users@seul.org Date: Sun, 06 May 2007 22:04:29 +0200 Subject: Re: [pygame] PyGame Runtime Python eggs are supposed to be the way to go.see:http://blogs.nuxeo.com/sections/blogs/lennart_regebro/2006_04_13_easter-python-eggshttp://peak.telecommunity.com/DevCenter/PythonEggsbut not http://www.python-eggs.org/ which doesn't appear to have anythingto do with the topic at all.But I have never made one.Laura ___ Join Excite! - http://www.excite.com The most personalized portal on the Web!
Re: [pygame] PyGame Runtime
Will McGugan wrote: I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle So maybe what we want is an extension of py2exe that not only creates an executable but an installer as well? -- Greg
RE: [pygame] PyGame Runtime
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Ewing Sent: Monday, 7 May 2007 12:42 p.m. To: pygame-users@seul.org Subject: Re: [pygame] PyGame Runtime Will McGugan wrote: I know installers aren't that difficult to create. I've used Inno-setup myself, it's an excellent system - but its still a hurdle that most PyGame coders don't want to tackle So maybe what we want is an extension of py2exe that not only creates an executable but an installer as well? Or a separate Python module to create Windows installers, which py2exe could then use? BB The information contained in this transmission is confidential. It is intended for the named address only. If you are not the named address you may not copy, distribute or take any action in reliance upon this transmission
Re: [pygame] PyGame Runtime
Nathan wrote: is there a comparable python packaging system that works for a good portion of Linux distributions? (I'm NOT talking about rpm's, ebuilds, etc.) Someone needs to get all the Linux distributors, bang their heads together and make them come up with a single packaging system that works on all distributions. And MacOSX .app bundles would be a good thing to model it on. -- Greg
