Re: [pygame] Promoting cheeseshop/pypi for game releases?

[René Dudfield]

@Daniel, Yeah, I think a GUI for apps using virtualenv, and pip would be
quite possible and good. (I wonder if such a thing already exists?)

I know when setuptools and easy_install were first being made, that was the
plan. There was a gui in their app which used them to install plugins for
the app. Also, I know some IDEs provide tools for installing things with a
GUI (conda, pycharm etc).

cu.

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[René Dudfield]

Excellent! Thanks Thomas :)

I'll wait to hear feedback from DR0ID about the repo. In the mean time,
below is some more discussion on a couple of topics I'd like feedback on?

(sorry that it is such a wall of text)



src, gamelib, and mygamepackage

1). One thing that is different in the skellington layout from the
sampleproject one is that the naming is a bit more specific for where the
code goes in skellington.

https://bitbucket.org/dr0id/pyknic/src/92449d2874e031da948fd7c537df0bb7106b2676/pyknic-skellington/?at=default
gamelib/
data/

Why this is good? Because you can start writing your code without first
having to decide the name. It's a small thing, but in the context of game
competitions it's more important. I'm not sure if it's really worth keeping
that idea though.

This would be the sampleproject layout after doing "skellington create
mygamepackage"
mygamepackage/
data/

(Where skellington is the name of our tool. It could be pygame create... or
whatever)


The benefits of this are that you can go into the repo and do:
import mygamepackage

Any it works. Because mygamepackage is just a normal package.

You can also do:
python mygamepackage/run.py


Whilst naming is important, the name of the package doesn't need to be the
name of the Game. I've worked on projects where the company name, and app
name changed at least three times whilst the package name stayed the same.
So I don't think people need to worry so much. Also, it's not too hard to
change the package name later on.


My vote would be to follow the python sampleproject way of doing things.



Data folder, and "get_data".

2). The other aspect I'm not sure of is having a data folder outside of the
source folder. Having it inside the source folder means you can more easily
include it inside a zip file for example. It also makes packaging slightly
easier. Since you can just use from within a MANIFEST.in a recursive
include of the whole "mygamepackage" folder.

Having data/ separate is the choice of the sampleproject, and the
skellington.

I haven't really seen a modern justification for keeping data out of the
package folder? I have vague recollections of reasons being: 'because
debian does it'. My recollection is that Debian traditionally did it to
keep code updates smaller. Because if you only change 1KB of source code,
there's no point having a 20MB update every time.

A bonus of keeping data separate is that it forces you to use relative
addressing of file locations. You don't hardcode "data/myfile.png" in all
your paths. Do we recommend the python way of finding the data folder? This
is package_data, and data_files setup attributes.
https://github.com/pypa/sampleproject/blob/master/setup.py

They are a giant pain. One, because they require mentioning every single
file, rather than just the whole folder. Two, because they require you
updating configuration in both MANIFEST.in and setup.py. Also, there are
different files included depending on which python packaging option you use.

See the packaging.python.org documentation on including data files:
https://packaging.python.org/distributing/?highlight=data#data-files

Another issue is that, using the python way pkg_resources from setuptools
needs to be used at runtime. pkg_resources gets you access to the resources
in an abstract way. Which means you need setuptools at runtime (not just at
install time). There is already work going into keeping that separate here:
https://github.com/pypa/pkg_resources So I'm not sure this will be a
problem in the next months.

I haven't confirmed if pkg_resources works with the various .exe making
tools. I've always just used file paths. Thomas, does it work with Pynsist?

Having game resources inside a .zip (or .egg) makes loading a lot faster on
many machines. pkg_resources supports files inside of .egg files. So, I
think we should consider this possibility.

A single file .exe on windows used to be possible with pygame including all
of the data. It worked by adding a .zip file to the end of the .exe and
then decompressing that before running it. It actually made startup time
slower, but the benefit was distribution was pretty easy. However, putting
everything in a .zip file was just as good.

Perhaps we could work on adding a find_data_files() type function for
setuptools, which would recursively add data files from data/. We could
include it in our 'skellington' package until such a thing is more widely
installed by setuptools.

Despite all the issues of having a separate data/ folder, it is the
convention so far. So my vote is to follow that convention and try fixing
the issues in setuptools/pkg_resources.



Too many files, too complex for newbies.

3) Modern python packages have 20-30 files in the root folder. I have heard
the complaint many times that it makes it difficult to figure out where to
put things. It makes it complex. This is the strong feedback I got in one
pyweek where lots of people decided to use the older skellington instead.

We 

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Thomas Kluyver]

On 1 February 2017 at 06:31, René Dudfield  wrote:

> But now with free CI options... it seems more possible to make a tool
> which builds peoples apps for them. But again would require maintenance. By
> leaning on the python packaging infrastructure, we access to all the tools
> for packaging libraries.


I agree that leveraging the library packaging ecosystem to make app
packaging easier is a good idea. Part of why I pushed hard for pygame to
have wheels on PyPI (and a release ;-), is because that makes it very easy
to build a Windows installer with Pynsist. I'd be happy to help set up a
skeleton/example repo which uses Pynsist and a CI service like Travis to
build installers.

Eventually, I'd like it to be the case that game creators don't need to
build wheels or put their game on PyPI to distribute it. As you suggest, it
should be enough to upload the files to a website, or run something
locally, to build installers/packages for different platforms. But that
vision is clearly some way off, and I accept that PyPI is a decent interim
solution. Doing 'pip install bullet_dodger' (thanks Jorge for the example)
certainly beats unpacking a tarball and finding out about dependencies by
trial and error.

Thomas

Re: [pygame] Promoting cheeseshop/pypi for game releases?

[Jorge]

Am 01.02.2017 um 07:31 schrieb René Dudfield:
> I agree that many of the things on your wonderful list would be
> useful. I've also starting adding them to a plan (see at the bottom).
>
> I still think promoting packaging is still very useful, and a very low
> effort thing to do.
>
> Game distribution for general users should definitely not happen on
> the cheeseshop. Especially not as the primary method. The audience I'm
> thinking of is more other game developers (and people who will
> eventually become developers).
>
> I think the package index is better than 'random free upload webpage
> on the internet', which many are uploading code to now. Also pyweek
> has proven that a code template can provide a helpful structure for
> people using other packaging tools. Often times, eventually, someone
> figures out the latest work arounds for the various packaging tools
> and a script appears which works for many platforms. Of course every
> year platforms update, and the packaging tools develop new
> features...*cough* bugs *cough* that means that last years script has
> stopped working.
>
> But now with free CI options... it seems more possible to make a tool
> which builds peoples apps for them. But again would require
> maintenance. By leaning on the python packaging infrastructure, we
> access to all the tools for packaging libraries.
>
> The pygame website, and things like pyweek have thousands of games on
> there already. There's also thousands of people who look through those
> games every month. I'm fully intending to improve apon the features on
> the website for people releasing games.
>
> We need to try and make it as simple as dragging a game folder onto
> website. Because that's basically what people are doing to upload
> their games. Some people don't even know git, github, pypi, travis...
> all those things. Hopefully we can take much of the tediousness out of it.
>
>
> I'm hoping to collaborate with DR0ID, who is working on the pyweek
> 'skellington' base code on a file structure we can use by combining it
> with the pypa 'sampleproject'.
>
> I've started writing a series of blog posts about all this stuff...
> about the benefits of packaging games for the python community, what
> we can do to make distributing games easier.
> http://renesd.blogspot.com/2017/01/promoting-pypi-for-python-game-releases.html
> http://renesd.blogspot.com/2017/01/using-common-file-layout-lets-us-create.html
>
>
> Looking forward to the day when we have build bots package games up
> for android, mac, windows, ubuntu, pip, raspberrypi etc, etc, then
> have things automatically do release announcements and such.
>
>
> cheers!
>
>
>
>
> On Mon, Dec 26, 2016 at 1:17 PM, Thomas Kluyver  > wrote:
>
> My tldr: PyPI and pip are the wrong tools for game distribution,
> there are better places to focus effort.
>
> If the instructions to get your game say 'pip install yourgame',
> you're limiting your audience to people who have Python installed
> and are comfortable with the command line. Even among those
> people, you may find yourself having to explain about using pip3
> on some systems, or about why running 'sudo pip ...' is a bad idea.
>
> PyPI and pip exist primarily to distribute Python libraries. We
> use them secondarily to distribute command-line tools, because
> it's a quick and easy alternative to building packages for
> different platforms, and the kind of people who use a tool like
> 'nosetests' know how to install it with pip. They're not a good
> fit for GUI applications where the user shouldn't need to know
> that Python is in use.
>
> So, where do I think we should focus effort?
>
>   * Tools to package up Python /applications/ into convenient
> installable bundles
>   o Shameless plug: Pynsist is a tool I made to build Windows
> installers.
>   o I'd particularly like to see work around the new Linux
> application packaging formats, Flatpak and Snappy. Can we
> make a tool that takes some form of description and builds
> both kinds of package?
>   o The BeeWare projec (http://pybee.org/ ) is doing some
> interesting work on packaging for mobile platforms.
>   o Stretch goal: can we start with a single application
> description and build packages for various platforms? I'm
> sceptical, but it would be cool, even if the packages
> lacked some polish.
>   * Guides on preparing & submitting games to various app
> marketplaces:
>   o Platform owners: Microsoft, Apple, Google, Canonical...
>   o Third party: Steam, Itch...
>   * (Maybe) A better catalogue of non-professional games, for
> creators who may not want to put their games up on Steam or
> whatever. I'm still unsure if there's an actual gap to be
> filled here, 

Re: [pygame] Mac PyGame installation question

[René Dudfield]

Hello,

I agree that a virtualenv is useful. But maybe too complex a topic to start
newbies with?

The problem with Apple python is that it is an old python 2.7, and that you
need special rights to install a new virtualenv and pip anyway.

The new python cleans up a ton of little things that makes programming
easier. Not to mention the newer IDLE, which is lots better in python3.6.

Two questions you don't get with python3.6:
u'Some text' - What is the u'' for?
1 / 2 == 0 -- why is this not 0.5?





On Tue, Jan 31, 2017 at 7:03 PM, Chris  wrote:

> I would argue that using virtualenv with pip would actually be the better
> solution here, as there are no special rights required for that setup
> (asuming virtualenv is installed), and I find that having two pythons
> installed can be confusing at times.
>
> For virtualenv just follow this guide (https://virtualenv.pypa.io/en
> /stable/userguide/#usage) for setting it up, then execute get-pip.py (
> https://pip.pypa.io/en/stable/installing/) after having sourced your
> virtualenv. At that point pip will install everything into your new
> environment site-packages instead of the system one.
>
> If you have any further questions specifically about using virtualenv feel
> free to send me an email or just ask here. (I actually have access to a mac
> at work so I can do the install tomorrow and send you a script if you want.)
>
> On 2017-01-31 09:36 AM, René Dudfield wrote:
>
>> Hello,
>>
>> I think it's best to install the python 3.6 with homebrew. Then use pip
>> to install pygame.
>>
>> People often recommended to NOT use the python that comes with OSX, as
>> that is for system tools. So it's best to avoid installing things there.
>> Also you need special permissions.
>>
>> This 'works for me' on my 10.11.6 macbook, and for a lot of others.
>>
>>
>> best regards,
>>
>>
>>
>> On Tue, Jan 31, 2017 at 5:57 AM, Irv Kalb  i...@furrypants.com>> wrote:
>>
>>
>> At one of the school where I teach, the IT department is
>> responsible for configuring all the student and teacher
>> computers.  They are the only ones who have the system passwords.
>>
>> One of my classrooms is a Mac classroom - the teacher's computer
>> and all the student computers are Macs (my other classroom is all
>> Windows).  I did a quick check today and found that PyGame is not
>> install on the Macs (it is install on the Windows systems).  I
>> want to contact the IT department and ask them to install PyGame
>> on all the Macs. However, I'm not sure what the proper
>> installation is.
>>
>> All the Macs are running OS X 10.11 El Capitan, and have Python
>> 2.7.(something) installed.  Since I cannot install anything on
>> these systems, I need to give clear instructions to the IT
>> department.  I have installed PyGame on Macs with OS X 10.9 (where
>> I needed to install 32 bit Python), and recently on a Mac with OS
>> X 10.12.
>>
>> Can someone tell me what is the proper procedure for installing
>> PyGame onto Macs with OS X 10.11?  (I'm hoping that it is as
>> simple as downloading from the PyGame download page and running
>> the installer - PyGame 1.9.1 would work fine for these students.)
>>
>> Thanks in advance,
>>
>> Irv
>>
>>
>>
>