Regression with cx_support in 1.4.0rc4

[ibell]

I tried to package an app dependent on mpl using 1.3.1 - no problems.

When I upgrade to 1.4.0rc4, I get the following traceback when I try to start my app. Not so nice. Looks like it is looking for an absolute path for styles within the zip file which is a no-no obviously.

[efiring]

In style/core.py, the call to abspath is doing it:

_here = os.path.abspath(os.path.dirname(__file__))
BASE_LIBRARY_PATH = os.path.join(_here, 'stylelib')

[WeatherGod]

This should be using pkg_resources. Preferably the "resource_stream" method
that provides a file-like object. Then, if it isn't already done, the style
files needs to be noted in the setup.py as data. Using "resource_filename"
works in some cases, but probably not for this packaging solution.

On Tue, Aug 19, 2014 at 1:12 PM, Eric Firing notifications@github.com
wrote:

In style/core.py, the call to abspath is doing it:

_here = os.path.abspath(os.path.dirname(file))
BASE_LIBRARY_PATH = os.path.join(_here, 'stylelib')

—
Reply to this email directly or view it on GitHub
#3385 (comment)
.

[ibell]

More generally it would be great if you could add a unit test for
cx_freezing support. cx_Freeze, while it has its issues, is currently the
only cross platform packager supporting py2 and py3. I've got quite a few
projects dependent on the combo of MPL/wxpython/cx_Freeze.

On Tue, Aug 19, 2014 at 7:19 PM, Benjamin Root notifications@github.com
wrote:

This should be using pkg_resources. Preferably the "resource_stream"
method
that provides a file-like object. Then, if it isn't already done, the
style
files needs to be noted in the setup.py as data. Using "resource_filename"
works in some cases, but probably not for this packaging solution.

On Tue, Aug 19, 2014 at 1:12 PM, Eric Firing notifications@github.com
wrote:

In style/core.py, the call to abspath is doing it:

_here = os.path.abspath(os.path.dirname(file))
BASE_LIBRARY_PATH = os.path.join(_here, 'stylelib')

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/issues/3385#issuecomment-52666711>

.

—
Reply to this email directly or view it on GitHub
#3385 (comment)
.

[efiring]

The bug certainly needs to be fixed ASAP, but doing it right might take some time. It will affect relatively few users. Therefore I don't think it should block 1.4.0, though if someone can come up with a good fix in time for 1.4.0, so much the better.

[WeatherGod]

Let's target this for a 1.4.1. We can't keep holding off 1.4.0. I do have
some experience with using pkg_resources, so I will see what I can put
together, but we all know that it is doubtful that I can put it together in
any sort of reasonable timeframe for 1.4.0.

On Tue, Aug 19, 2014 at 3:24 PM, Eric Firing notifications@github.com
wrote:

The bug certainly needs to be fixed ASAP, but doing it right might take
some time. It will affect relatively few users. Therefore I don't think it
should block 1.4.0, though if someone can come up with a good fix in time
for 1.4.0, so much the better.

—
Reply to this email directly or view it on GitHub
#3385 (comment)
.

[ibell]

Breaking cx_Freeze support is a pretty big deal IMHO. Again, I reiterate
that it would be good if a cx_Freeze test could be integrated into the unit
testing. Packaging python programs is a big pain, and the fact that the
HEAD repo can't package is not good.

On Wed, Aug 20, 2014 at 3:31 AM, Benjamin Root notifications@github.com
wrote:

Let's target this for a 1.4.1. We can't keep holding off 1.4.0. I do have
some experience with using pkg_resources, so I will see what I can put
together, but we all know that it is doubtful that I can put it together
in
any sort of reasonable timeframe for 1.4.0.

On Tue, Aug 19, 2014 at 3:24 PM, Eric Firing notifications@github.com
wrote:

The bug certainly needs to be fixed ASAP, but doing it right might take
some time. It will affect relatively few users. Therefore I don't think
it
should block 1.4.0, though if someone can come up with a good fix in
time
for 1.4.0, so much the better.

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/issues/3385#issuecomment-52685500>

.

—
Reply to this email directly or view it on GitHub
#3385 (comment)
.

[WeatherGod]

You are more than welcome to read up on pkg_resources and submit a patch
yourself. Please bear in mind that we originally planned to release 1.4.0
four months ago! This release is long overdue. As with any release, there
will be all sorts of critical bugs discovered shortly afterwards that will
necessitate a quick bugfix release. I can assure you that 1.4.1 will
include a fix for cx_Freeze.

I also have nothing against adding some sort of automated build test for
cx_Freeze, but I don't think any of the regular developers have any clue
how to use that tool, so your help in this would be greatly appreciated as
well.

On Wed, Aug 20, 2014 at 3:16 AM, Ian Bell notifications@github.com wrote:

Breaking cx_Freeze support is a pretty big deal IMHO. Again, I reiterate
that it would be good if a cx_Freeze test could be integrated into the
unit
testing. Packaging python programs is a big pain, and the fact that the
HEAD repo can't package is not good.

On Wed, Aug 20, 2014 at 3:31 AM, Benjamin Root notifications@github.com
wrote:

Let's target this for a 1.4.1. We can't keep holding off 1.4.0. I do
have
some experience with using pkg_resources, so I will see what I can put
together, but we all know that it is doubtful that I can put it together
in
any sort of reasonable timeframe for 1.4.0.

On Tue, Aug 19, 2014 at 3:24 PM, Eric Firing notifications@github.com
wrote:

The bug certainly needs to be fixed ASAP, but doing it right might
take
some time. It will affect relatively few users. Therefore I don't
think
it
should block 1.4.0, though if someone can come up with a good fix in
time
for 1.4.0, so much the better.

—
Reply to this email directly or view it on GitHub
<

https://github.com/matplotlib/matplotlib/issues/3385#issuecomment-52685500>

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/issues/3385#issuecomment-52723819>

.

—
Reply to this email directly or view it on GitHub
#3385 (comment)
.

[ibell]

I think I could help with setting up a test for cx_Freeze since I have
fought with that over many late nights. I think I basically understand
most of its quirks at the moment, certainly well enough to package my
applications, which are not all that interesting, but do involve the full
scipy stack as well as MPL and wxpython. Its a versioning nightmare, but I
can get it to work.

Go ahead with 1.4.0, I can put a warning for my users to use 1.3.1 for now.

On Wed, Aug 20, 2014 at 3:27 PM, Benjamin Root notifications@github.com
wrote:

You are more than welcome to read up on pkg_resources and submit a patch
yourself. Please bear in mind that we originally planned to release 1.4.0
four months ago! This release is long overdue. As with any release, there
will be all sorts of critical bugs discovered shortly afterwards that will
necessitate a quick bugfix release. I can assure you that 1.4.1 will
include a fix for cx_Freeze.

I also have nothing against adding some sort of automated build test for
cx_Freeze, but I don't think any of the regular developers have any clue
how to use that tool, so your help in this would be greatly appreciated as
well.

On Wed, Aug 20, 2014 at 3:16 AM, Ian Bell notifications@github.com
wrote:

Breaking cx_Freeze support is a pretty big deal IMHO. Again, I reiterate
that it would be good if a cx_Freeze test could be integrated into the
unit
testing. Packaging python programs is a big pain, and the fact that the
HEAD repo can't package is not good.

On Wed, Aug 20, 2014 at 3:31 AM, Benjamin Root notifications@github.com

wrote:

Let's target this for a 1.4.1. We can't keep holding off 1.4.0. I do
have
some experience with using pkg_resources, so I will see what I can put
together, but we all know that it is doubtful that I can put it
together
in
any sort of reasonable timeframe for 1.4.0.

On Tue, Aug 19, 2014 at 3:24 PM, Eric Firing notifications@github.com

wrote:

The bug certainly needs to be fixed ASAP, but doing it right might
take
some time. It will affect relatively few users. Therefore I don't
think
it
should block 1.4.0, though if someone can come up with a good fix in
time
for 1.4.0, so much the better.

—
Reply to this email directly or view it on GitHub
<

https://github.com/matplotlib/matplotlib/issues/3385#issuecomment-52685500>

.

—
Reply to this email directly or view it on GitHub
<

https://github.com/matplotlib/matplotlib/issues/3385#issuecomment-52723819>

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/matplotlib/matplotlib/issues/3385#issuecomment-52741702>

.

—
Reply to this email directly or view it on GitHub
#3385 (comment)
.

[cgohlke]

Py2exe is also broken. Wouldn't the mpl-data\stylelib directory be a better place for the .mplstyle files?

[cgohlke]

Moving the stylelib folder from matplotlib/style/ to matplotlib/mpl_data/ and the following patch work for me:

diff --git a/lib/matplotlib/style/core.py b/lib/matplotlib/style/core.py
index 02efe1f..8bd0d13 100644
--- a/lib/matplotlib/style/core.py
+++ b/lib/matplotlib/style/core.py
@@ -27,8 +27,7 @@ from matplotlib import rc_params_from_file
 __all__ = ['use', 'context', 'available', 'library', 'reload_library']


-_here = os.path.abspath(os.path.dirname(__file__))
-BASE_LIBRARY_PATH = os.path.join(_here, 'stylelib')
+BASE_LIBRARY_PATH = os.path.join(mpl.get_data_path(), 'stylelib')
 # Users may want multiple library paths, so store a list of paths.
 USER_LIBRARY_PATHS = [os.path.join(mpl._get_configdir(), 'stylelib')]
 STYLE_EXTENSION = 'mplstyle'

[tacaswell]

I like that solution and we can get it in for 1.4.0, could you put it in a pr? I will do it if a get to a real computer before you do.

I don't think moving a data file requires a new tv
Rc.

[ibell]

Awesome! Thanks very much guys - I look forward to using 1.4.0/

On Thu, Aug 21, 2014 at 3:58 AM, Eric Firing notifications@github.com
wrote:

Closed #3385 #3385 via
#3390 #3390.

—
Reply to this email directly or view it on GitHub
#3385 (comment).