Build OSX package from Windows

[Nacho de los Ríos Tormo]

Hello,

I produce a pure python package that users will install and update from an in-company http server using conda update. My development machine runs 64-bit Windows7.

I have written a script that automates building and uploading to server. It works OK for Windows packages, but I would like to also generate macOS packages.

The documentation only details how to convert the package from Win64 to macOS, but the converter complains it cannot cope with entry points.

If I do "convert --force", something it produces a package which contains the windows launcher exe and script files, but nothing like an entry point to call from macOS. And using the "--force" makes me uncomfortable.

The (sparse) documentation says that the "osx_is_app" will use "python.app" rather than "python" as entry point in OSX, but whether I set it to true or to false, I see no difference. Do entry points for OSX only work when the build is done on an OSX machine?

Is there a way to produce OSX packages directly from Windows?

Thanks for your help

[Michael Sarahan]

"noarch" packages are something of a work in progress, but you can try them.

The older way of doing things is at http://conda.pydata.org/docs/building/meta-yaml.html#architecture-independent-packages

The newer way is

build:

    noarch: python

which is supported in recent conda-build versions.  I don't know exactly what conda version is necessary to install these newer packages - probably recent 4.2 versions.

You might also want to try building your package on some CI service that provides Mac workers.  Building your package on a native platform will always be less prone to issues than finessing metadata.  I know Travis CI and Circle CI provide Mac workers.

--
Anaconda Community Support Group Brought to you by Continuum Analytics
---
You received this message because you are subscribed to the Google Groups "Anaconda - Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email to anaconda+unsubscribe@continuum.io.
To post to this group, send email to anac...@continuum.io.
Visit this group at https://groups.google.com/a/continuum.io/group/anaconda/.

[Björn Johansson]

I have travis set up to do this for my package here: pydna

look at the files ci.sh and .travis.yml which makes conda packages for Mac

/bjorn

[Nacho de los Ríos Tormo]

Thank you for your help

Following your suggestion, I have tried the "noarch" approach. However, when I specify "noarch: python" or "noarch_python: True", it happens that setup.py is called with Python 3. The code is Python 2.7, the yaml file specifies python 2.7 in the "run"section, and the build fails on the 2.7-isms.

Is there a way to produce noarch packages for 2.7?

Thanks again.

[Björn Johansson]

Hi, I think I read somewhere that noarch also indicates 

no dependency on either 2.7 or 3.

if you need to specify python, the best way is probably to make packages the normal way and use conda convert.

/bjorn

--

Anaconda Community Support Group Brought to you by Continuum Analytics
---

You received this message because you are subscribed to a topic in the Google Groups "Anaconda - Public" group.
To unsubscribe from this topic, visit https://groups.google.com/a/continuum.io/d/topic/anaconda/dR3r5H5sSnE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to anaconda+unsubscribe@continuum.io.

To post to this group, send email to anac...@continuum.io.
Visit this group at https://groups.google.com/a/continuum.io/group/anaconda/.

--

______O_________oO________oO______o_______oO__
Björn Johansson
Assistant Professor
Departament of Biology
University of Minho
Campus de Gualtar
4710-057 Braga
PORTUGAL
www.bio.uminho.pt
Google profile

Google Scholar Profile
my group
Office (direct) +351-253 601517 | (PT) mob.  +351-967 147 704 | (SWE) mob.  +46 72 740 60 20
Dept of Biology (secr) +351-253 60 4310  | fax +351-253 678980

[Nacho de los Ríos Tormo]

I got to generate in my Win64 machine noarch packages that are installed and run by my macOS machine.

The packages are "noarch" to the extent that they do run on Win64 and macOS, but they only run with python 2.7. This is against the grain of what a "noarch" package is supposed to do, but it seems naive to pretend to produce _practical_ packages that run on any version of Python; sticking to 2.7 and 3.x is certainly possible for sophisticated software, but even 2.6 starts to be much more difficult.

Anyway, it is a known hack, but not an official way to do things. Maybe in the future it will turn to be so, because the current official approach seems a bit absurd.

Anyway, I found the hack mentioned here: https://github.com/conda/conda-build/issues/542

What I actually did was this:

Specify noarch in the yaml build section:

build:

  noarch_python: True

  ...

Specify python != 3 in the yaml requirements-build section:

requirements:

  build:

    - python <2.8

That was enough to prevent Python 3 from being pulled and used to build the package, so all the 2.7 code stopped producing errors.

However, later in the build, conda build code disliked the name given to the package and asserted on the lack of the "py_" substring. This was cured with was seems to be the extraofficial workaround for this issue:

Force the "py_27" substring into the package name in the yaml build section:

build:

  string: py_27

  noarch_python: True

I have also specified an entry section both in setup.py and in the yaml. 

 entry_points:

  - mypackage = mypackage.main:main

I don't know if one can be done without, but the result is that on OSX, in the bin folder for the package, a shell file named as "mypackage" that calls into the entry point.

Next, I need to add some sort of launcher icon, and cure some incompatibilities between Win and OSX brought by the different versions of packages available for both platforms.

BTW, is Pyside alive? Is Anaconda alive? Pyside 1.2 has been available for a couple years now, and no newer versions seem to be coming. And Anaconda OSX is still stuck on 1.1, which is even older.

[Ian Stokes Rees]

Hello,

I can’t comment on most of your email, but to this point:

On 12/20/16 4:20 AM, Nacho de los Ríos Tormo wrote:

Is Anaconda alive?

The answer is “yes”. What would make you think otherwise? If you are having problems upgrading Anaconda that might be one reason. For that, I’d suggest you do the following:

conda update conda
conda install anaconda=4.2

Then note any conflicts, uninstall them, and try the second command conda install anaconda=4.2 again. Repeat until it works. Then reinstall the previously conflicting packages in order to get versions of those that work with Anaconda 4.2.

Let us know if you have trouble with those steps.

Someone else may be able to respond to your other questions.

Ian

---

---

Ian Stokes-Rees, PhD
Computational Scientist, Product Marketing Manager
1.617.942.0218
ijst...@continuum.io
@ContinuumIO @ijstokes

.

​

[Nacho de los Ríos Tormo]

Thank you Ian. I asked because I have used Anaconda for an in-house tool, and hope it stays maintained in the future.

Specifically, I asked about Pyside because it has not been updated in the Anaconda repository for a very long time. I did find an up-to-date version in conda-forge, though, but adding the whole conda-forge repo brough in a new build for the same version of Qt that broke my app. I fixed that by removing the conda-forge channel but adding its pyside package to my server, but in the end I removed the whole dependency to pyside, which was little, because the solution seemed fragile and also because I don't trust upstream pyside to be very much alive.

Still I was worried that conda-forge Pyside package had not made it to the main channel, when the package in the main channel is years old.

Anyway, thanks for a great distribution that works amazingly well and puts no obstacles in the way for developers.

--

[Ian Stokes Rees]

On 12/22/16 10:58 AM, Nacho de los Ríos Tormo wrote:

Thank you Ian. I asked because I have used Anaconda for an in-house tool, and hope it stays maintained in the future.

Specifically, I asked about Pyside because it has not been updated in the Anaconda repository for a very long time. I did find an up-to-date version in conda-forge, though, but adding the whole conda-forge repo brough in a new build for the same version of Qt that broke my app. I fixed that by removing the conda-forge channel but adding its pyside package to my server, but in the end I removed the whole dependency to pyside, which was little, because the solution seemed fragile and also because I don't trust upstream pyside to be very much alive.

Still I was worried that conda-forge Pyside package had not made it to the main channel, when the package in the main channel is years old.

Anyway, thanks for a great distribution that works amazingly well and puts no obstacles in the way for developers.

Conda-Forge is a community driven effort to create Conda packages.  We certainly collaborate with them, but as you've discovered they have a different package build system and when you go with one of their packages you need to get as many of your dependencies as possible from conda-forge lest you end up with package build mis-matches, which is probably what you are experiencing with PySide.

I am not involved in the Conda package building process at Continuum, so I cannot tell you the status of PySide and whether it will be updated in the "Continuum curated" channel we call "defaults".

Ian

[Björn Johansson]

There are many versions of pyqt in the cannels as well.

I think this might be better maintained than pyside?

/bjorn