Packaging in mac os

Mac OS X package modifies files in my home directory instead of installing to Applications

I am trying to figure out the best way to distribute a graphical Qt application to users of Mac OS X.

I have learned about pkgbuild, productbuild, and used them to create flat packages with a .pkg extension.

However, I am seeing some very strange behavior when I try to install such a flat package on Mac OS X 10.11. It looks like the Mac OS X installer for these packages searches my home directory for the application I am trying to install. If it finds the application there, then it actually steals that application, changing the ownership of those files to root, and it fails to install the application in the /Applications folder where I wanted it to be installed.

The expected behavior is that the package should always install my application into the /Applications directory, and it should not modify the ownership of any files in my home directory.

This seems really weird. What is going on and how I can fix it? The flat packages seem nice, but I want to guarantee that they always install the application in the right place and I don’t want them to be modifying files in the user’s home directory.

Steps to reproduce the problem

Install Homebrew in your home directory.

Run brew install qt5 to install Qt5.

Make a new directory with these three files:

Info.plist.in:

main.cpp:

test.sh:

Now run test.sh by typing ./test.sh in a Terminal. On my computer, the output looks something like this:

(Clearly, pkgbuild is detecting components inside my staging folder. I wish it would not do that. I want it to simply install all those files into the user’s /Applications directory. If it treats the files specially just because they have Info.plist files, that is probably a bad thing.)

Next, install the package by running open app.pkg and following the on-screen GUI:

Run ls /Applications/abc.app and you can see that the application was not installed in the expected place.

Run ls -l staging or find . -uid root and you can see that the files in staging/abc.app are now all owned by the root user, which is unexpected.

Now delete the staging directory with sudo rm -rf staging . Try installing the package again. This time, since the installer didn’t find the app in my home directory, it has successfully installed it to /Applications .

Alternatives

I am not interested in just packaging the .app folder into a .dmg file because my app will actually have a GUI and a command-line component, and it would be hard to get the command-line component onto the user’s path with that method. With flat packages, I can easily get the command-line component onto the path by adding a file to /etc/paths.d .

Are there better tools for authoring Mac OS X flat packages?

Is the source code of pkgbuild available so I can figure out what it is doing?

I might try the more complex procedure described in this answer to see if that helps.

Источник

Platypus и Packages. Создаём и устанавливаем программы на macOS

Очень часто бывает необходимо собрать код, написанный на Python, в приложение для Windows, Linux или OS X. Да, для этого действительно существует множество пакетов, таких как кросс-платформенные cx_Freeze и PyInstaller, а также обособленных py2exe и py2app. Но для macOS существует возможность избежать возни с созданием установочного файла.

Нужно сказать, что в отличии от Windows, программа на MacOS это просто папка, с расширением .app а вот исталлятор имеет расширение .pkg.

Создаём программу

Для создания программы из скрипта, используем программу Platypus. Это бесплатная, open-source программа, распространяемая под BSD лицензией. Вот так выглядит единственное главное окно этой программы:

• В поле App Name указываем имя приложения, это то как программа будет отображаться в списке программ и Launchpad-е.
• В выпадающем списке Script Type указывается язык скрипта, в нашем случае это Python, можно указать путь к компилятору, если, например, на компьютере их несколько.
• В поле Script Path можно создать свой новый скрипт (кнопка «+ New»), а можно выбрать уже готовый скрипт (кнопка «Select Script»).
• В выпадающем списке Interface можно выбрать тип приложения, в случае если у вас консольное приложение, не требующее ввода текста пользователем, рекомендую выбрать Text Window.
• Слева от вышеперечисленных полей, есть поле выбора иконки приложения, в составе программы идёт несколько стандартных иконок, но можно выбрать свою.
• Следующий блок полей отвечает за информацию о программе, которая предоставляется в стандартном меню «О программе». Это уникальный идентификатор, автор программы и её версия. Кроме этого можно указать свойства для запуска, например запуск с правами администратора или работа в бэкграунде.
• И второй по важности блок, это дополнительные файлы. Так как в MacOS приложение — это не только исполняемый файл, но и все необходимые для работы приложения файлы и папки. Нажатием на кнопку «+» можно выбрать как и отдельные файлы, так и целые папки.
• После заполнения всех полей, кнопка «Create App» становится активной, нажимаем её и получаем на выходе симпатичный файлик с расширением .app.

Мы собрали приложение, которое запуститься на любом компьютере под управлением macOS, но этого не достаточно для удобного распространения и установки конечным пользователем. Поэтому создадим для нашего приложения установочный пакет.

Создаём инсталлятор

Для создания установочных пакетов существует несколько программ, мы будем использовать Packages.

При открытии программы Packages нам предлагается выбрать тип установочного пакета, выбираем Distibution, так как Raw Package необходим тогда, когда нужно установить файлы в нестандартное расположение.

В следующем окне выбираем имя и расположение проекта. Имеет смысл в качестве расположения указывать рабочую папку проекта. После создания проекта открывается следующее окно, с большим количеством вкладок.

Пробежимся по ним:

• Settings — первая вкладка, здесь можно задать имя приложения, рабочую директорию, а так же необходимые условия для установки.
• Presentations — на этой вкладке устанавливается внешний вид самого пакета установки, добавляются переводы на различные языки, путь установки и прочие нюансы.
• Requirements & Resources — необходимые условия для установки и зависимости. Например если для работы программы необходимо Xcode Command Line Tools, то здесь это можно указать, и если проверка не будет пройдена, то установка отмениться.
• Comments — вкладка исключительно для заметок разработчика, представляет собой огромное поле для ввода текста.

Если в боковом меню выделить необходимый нам пакет(на картинке это My), то мы увидим следующую картину:

Во вкладке Settings, выбирается идентификатор, версия и можно указать, что попросить сделать пользователя после установки (выключить компьютер, перегрузиться и завершить сеанс пользователя). Кроме этого можно выбрать Location и дополнительные опции, например ввод админского пароля, изменение прав доступа к папке и прочее.

Во вкладке Payload происходит основной процесс, добавление файла приложения в проект. Необходимо выделить нужную папку для установки приложения, например Applications, нажать на кнопку «+» и выбрать уже готовый файл с расширением .app.

Во вкладке Scripts можно выбрать скрипты которые запустятся до или после установки.

После того как все пункты выполнены, нужно собрать проект. Это можно сделать либо из меню Build —> Build либо с помощью специальной короткой команды ⌘B.

После этого вы получите установочный файл, которым можете поделиться с вашими друзьями и партнёрами.

Ссылки на необходимые файлы и обучающее видео

Platypus — программа для сборки .app;

Packages — программа для сбоки pkg;

Вот это — отличная видеоинструкция по работе с программой Packages.

Небольшое дополнение

По умолчанию, Platypus просто запускает скрипт, но почти всегда нам надо запускать программу на компьютере, где не установлен python. Для такого случая есть специальный лайфхак:

В Platypus в качестве типа скрипта выбираете shell script, нажимаете на + и пишете следующий код:

Где

• MyApp.app — это имя вашего приложения
• /compiler/bin/python — путь до компилятора
• main.py — необходимый скрипт

Теперь, если вы соберёте программу и переместите её в папку Applications, то она запустится со своим компилятором.

Источник

Homebrew: Менеджер пакетов для OS X

Все менеджеры пакетов в Unix имеют определенные недостатки и большинство Linux-дистрибутивов пытаются по-разному эти недостатки обойти. В этом посте я расскажу про Homebrew — новый менеджер пакетов, нацеленный на простоту использования.

До Homebrew было несколько различных попыток создать эффективные пакетные менеджеры для OS X. Две наиболее популярные вылились в итоге в Fink и Macports, но у каждой из них все равно есть свои острые углы. В частности, в обоих создание своих пакетов или портов является черезчур сложным.

В Homebrew создавать новые пакеты и работать с ними проще пареной репы. Давайте посмотрим.

Что оно делает?

Основная мысль очень проста. Homebrew упрощает и автоматизирует монотонные действия по скачиванию и сборке пакетов. Если вам надоели бесконечные ./configure && make && make install , Homebrew поможет.

Зачем оно?

Как я уже заметил выше, для OS X уже есть два решения: Fink и MacPorts. Если какое-то из них у вас уже установлено и всем устраивает — отлично. Но если вы имели неудачный опыт с ними в прошлом, я сильно рекомендую попробовать Homebrew. С ним намного проще. Плюс, его легко модифицировать, ведь он состоит всего из нескольких сотен строк кода на Ruby.

Homebrew не навязывает никакой строгой структуры и путей. По-умолчанию, он устанавливается в /usr/local , но его можно поставить куда угодно. Все пакеты устанавливаются в директории в специальном «подвале» (cellar), например Cellar/git/1.6.5.4/ . После установки Homebrew делает симлинки в стандартные Unix-директории. Ручная установка каких-то пакетов не из Homebrew отлично уживается с ними.

Это редко может понадобиться, но пакеты можно ставить напрямую из систем контроля версий. Если у пакета есть публичный git, svn, cvs или mercurial репозиторий, всегда можно собрать самую свежую devel-версию прямо оттуда простым brew install .

Кстати, установка занимает меньше времени, поскольку Homebrew старается избегать дублирования пакетов. Например, она не ставит очередную версию Perl в качестве зависимости, поскольку в системе уже есть готовый и работающий Perl. Плюс, Homebrew задуман так, чтобы вам не приходилось использовать sudo при работе с пакетами.

Звучит неплохо. Как это установить?

Первая и единственная зависимость Homebrew — OS X Developer Tools, которые есть на любом установочном диске с OS X и доступны для бесплатного скачивания с сайта Apple.

Самое простое — установить в /usr/local . Это можно сделать весьма просто:
# Присваиваем папку /usr/local себе, чтобы не использовать sudo
sudo chown -R `whoami` /usr/local
# Чиним права на mysql, если он у вас установлен
sudo chown -R mysql:mysql /usr/local/mysql
# Скачиваем и устанавливаем Homebrew с гитхаба
curl -L github.com/mxcl/homebrew/tarball/master | tar xz —strip 1 -C /usr/local

Все, установка завершена. Давайте проверим что все работает:
brew install wget
brew info git

На сайте Homebrew есть wiki, где можно почитать всякого интересного про интеграцию с Rubygems, CPAN и Python EasyInstall.

Следить за обновлениями Homebrew тоже достаточно просто:
brew install git
brew update

Если у вас установлен git, вы можете в любой момент обновлять репозитории Homebrew и устанавливать последнии версии пакетов.

Создавать свои пакеты почти так же просто. Например, если бы в Homebrew не было бы пакета для wget, его создание выглядело бы примерно так:
brew create ftp.gnu.org/gnu/wget/wget-1.12.tar.bz2

После сохранения пакета, его можно протестировать: brew install -vd wget . Если что-то работает неправильно и вам нужна помощь по настройке пакета, на wiki есть много документации. Еще там можно посмотреть примеры создания таких пакетов как git или flac.

Если вы создали новый пакет и желаете поделиться им с сообществом, это тоже достаточно просто сделать с помощью гема github.

gem install json github
git add .
git commit -m «Added a formula for wget»
github fork
git push mastergitx

После того, как вы сделаете push, нужно в Homebrew issue tracker создать новый тикет с темой «New formula: ». Если там все в порядке, ваш пакет будет добавлен в главный репозиторий Homebrew и доступен всем пользователям.

Источник

What should be my python packages path for a user install on MacOS?

I’m on Mac OS X and I’ve heard that to avoid global installation of packages (using sudo) that might cause problems with the python files that OS X uses, the path to install python packages must be different than that of OS X.

Currently python executables are installed in :

Pip installs modules over here :

Python is used from here :

Are these paths safe?

4 Answers 4

If you are on OS X, you should also have Python in /usr/bin :

If you are using brew , the first python should be a symlink:

If you are not using brew , you will have to explain to us how you installed a second version of python .

You should also have at least two site-packages :

If you installed python using brew , you should also have pip :

You should probably upgrade that to the latest pip :

It should be safe to install python packages using /usr/local/bin/pip because they will be installed in /usr/local/lib/python2.7/site-packages . The /usr/local path is specifically for local software. Also, brew installs its files to /usr/local , so if you are using brew , you are already installing files there.

I am not sure why some folks say not to install any packages globally. I have never seen a reference that explained why this was a bad idea. If multiple users need the same package, it makes more sense to install it globally.

When I first started using virtualenv , it did not always work the way I expected it to. I had a machine with multiple users that needed requests , and because of problems with virtualenv , I wound up installing it globally using pip .

Both virtualenv and pip have improved a lot since I first started using them and I can see how using them can prevent some problems. If you are developing new software that needs the latest version of a package, virtualenv allows you to install the package without affecting the rest of the system. However, I still do not see why it is a bad idea to install packages globally.

Источник