Re: [pygame] Pygame 1.9.3?

2017-01-11 Thread Thomas Kluyver
On 11 January 2017 at 11:07, René Dudfield  wrote:

> Ah ok, cool. I thought you mentioned 32bit wheels didn't work because of
> something related to wheels. I'm working on getting the fixes upstreamed
> for 32bit. fluidsynth is the biggest one.


There is one annoying detail that's specific to wheels: because of the way
pip deals with 'fat' binaries on OSX, we need to tell it that our x64-only
wheels are x86+x64 (with the 'intel' tag), otherwise it won't try to
install them even where they do work. So if people with 32-bit-only Python
install it with pip, it will get installed and then fail to load with an
unhelpful error, rather than trying to install from source.

Thomas


Re: [pygame] Pygame 1.9.3?

2017-01-11 Thread René Dudfield
On Wed, Jan 11, 2017 at 9:51 PM, Thomas Kluyver  wrote:

> On 11 January 2017 at 10:31, René Dudfield  wrote:
>
>> As you say packaging can come after the release.
>>
>
> Do you want to do the 1.9.3 with Mac wheels or without? The people who
> tested them before the release indicated they were working, and you always
> hear disproportionately from the people having problems, so I think there's
> a good chance that they're useful to people despite all the issues that are
> coming up. On the one hand, it may be easier not to try to support Mac
> wheels for now; on the other hand I think it's more likely that the
> problems get solved if people are trying to use them.
>
>

I think we should go with the mac wheels. I did a couple of tests on some
systems and they work fine. I think they weren't working on my system when
I first tested because I had some outdated and hackily compiled sdl files
in my homebrew which were messing with it.




> Some of the breakages for macOS require fixes in SDL, and packaging for
>> 32bit requires much other work (seems whl doesn't work, so a .dmg could
>> possibly be made again).
>>
>
> I don't think there's any reason .whl can't work for 32-bit code on Macs.
> It's compiling the necessary dependencies that's the tricky bit, and trying
> to make things work for older OSX versions. Those challenges are presumably
> going to be the same however the code is packaged.
>
>

Ah ok, cool. I thought you mentioned 32bit wheels didn't work because of
something related to wheels. I'm working on getting the fixes upstreamed
for 32bit. fluidsynth is the biggest one.



> I updated the milestones for those issues. I think you should now be able
>> to modify milestones in bitbucket. Let's just assign milestones to things
>> we do going forwards, and clean up the other ones as they are done.
>
>
> Oops, I may have just gone through half of them clearing up milestones
> before I read that. ;-)
>
> Thomas
>

Oops! Sorry. Well, that's good that they're cleaned up now :)


Re: [pygame] Pygame 1.9.3?

2017-01-11 Thread Thomas Kluyver
On 11 January 2017 at 10:31, René Dudfield  wrote:

> As you say packaging can come after the release.
>

Do you want to do the 1.9.3 with Mac wheels or without? The people who
tested them before the release indicated they were working, and you always
hear disproportionately from the people having problems, so I think there's
a good chance that they're useful to people despite all the issues that are
coming up. On the one hand, it may be easier not to try to support Mac
wheels for now; on the other hand I think it's more likely that the
problems get solved if people are trying to use them.


> Some of the breakages for macOS require fixes in SDL, and packaging for
> 32bit requires much other work (seems whl doesn't work, so a .dmg could
> possibly be made again).
>

I don't think there's any reason .whl can't work for 32-bit code on Macs.
It's compiling the necessary dependencies that's the tricky bit, and trying
to make things work for older OSX versions. Those challenges are presumably
going to be the same however the code is packaged.


> I updated the milestones for those issues. I think you should now be able
> to modify milestones in bitbucket. Let's just assign milestones to things
> we do going forwards, and clean up the other ones as they are done.


Oops, I may have just gone through half of them clearing up milestones
before I read that. ;-)

Thomas


Re: [pygame] Pygame 1.9.3?

2017-01-11 Thread René Dudfield
Hi,

I think we'll have to think on the mac situation later. There's really way
too much to test properly over the different versions to fix quickly. I'll
come up with a test plan for OSX and gather together reasons for not
supporting various combinations. (eg. whl on 32bit). As you say packaging
can come after the release. Some of the breakages for macOS require fixes
in SDL, and packaging for 32bit requires much other work (seems whl doesn't
work, so a .dmg could possibly be made again).

I updated the milestones for those issues. I think you should now be able
to modify milestones in bitbucket. Let's just assign milestones to things
we do going forwards, and clean up the other ones as they are done.

Next from that list of mine... I'll work on updating the release notes. I
thought I had an issue open already for that... but can't find it right now.


cheers,




On Tue, Jan 10, 2017 at 8:17 PM, Thomas Kluyver  wrote:

> On 10 January 2017 at 00:21, René Dudfield  wrote:
>
>> The mac problems are pretty severe... I'm looking into them right now.
>> Maybe we can roll back some of the changes fairly easily, because it was
>> working at least on the macs I tested with before the pre- release.
>
>
> Could it be that it's the wheels that are the problem, and when you tested
> the pre-release you installed from source? If the Mac wheel builds aren't
> working, maybe we should do a release without them and leave it up to
> downstream packagers (like Homebrew and Macports) to provide precompiled
> packages for Macs.
>
> > There's a few items still open in the 1.9.3 milestone. Let's set them to
> another milestone if we're not going to do them.
>
> There are a bunch still open in the 1.9.2 milestone. I don't think I have
> the ability to create new milestones, nor to change milestones for more
> than one issue at once.
>
> Thomas
> 
>