@tryge if you are ok with it I would take this over

Please, go ahead!

As discussed in #1184, it would be also nice to build mac os x binaries using travis.

But adding Homebrew Formula has the highest priority, I hope someone with a Mac can pick this up!

I created a Homebrew formula and a tap for Elektra.

@markus2330 I transferred the repo to you Markus, since I would have needed admin status to move the repo to the ElektraInitiative organization. Can you please move the repository from your personal account to the ElektraInitiative organization?

I created a Homebrew formula and a tap for Elektra.

Thank you, that is really great!

Does it also includes binary packages for the latest release?

I transferred the repo to you Markus, since I would have needed admin status to move the repo to the ElektraInitiative organization. Can you please move the repository from your personal account to the ElektraInitiative organization?

Sorry, where can I find it? In https://github.com/sanssecours/homebrew-elektra I do not have the button "settings" (which would be required for transfering).

Why not simply cloning it? (Or recreating one by pushing the same commits into it)

Btw. Is it possible to bring this Formula also upstream to brew?

@omnidan Can you test if the tap/bottle works for you, too?

Should we create issues about the tap/bottle here or at
https://github.com/ElektraInitiative/homebrew-elektra?

Does it also includes binary packages for the latest release?

Not yet, creating a binary package does not look to be that hard though. I will take a look.

Sorry, where can I find it? In https://github.com/sanssecours/homebrew-elektra I do not have the button "settings" (which would be required for transfering).

Thanks you for the admin access. I just transferred the repo.

Btw. Is it possible to bring this Formula also upstream to brew?

Yes. I wanted to do that first, but as far as I can tell the Homebrew developers are kind of picky about what they accept. Especially the text

We frown on authors submitting their own work unless it is very popular.

sounds like an issue.

I just transferred the repo.
Not yet, creating a binary package does not look to be that hard though. I will take a look.

Thanks!

Thanks you for the admin access.

Anytime again if you need it. We can also discuss permanent admin access.

Yes. I wanted to do that first, but as far as I can tell the Homebrew developers are kind of picky about what they accept. Especially the text

It is good if we get some feedback, even if they won't accept it.

We frown on authors submitting their own work unless it is very popular.

I understand this sentence that you should not submit a formular for your own work (=repo written by you alone). This is hardly the case here.

A binary Homebrew package (bottle) is now available. If someone wants to try the formula please follow the steps below.

1. Please run brew doctor and remove all fragments of Elektra that the command reports.
2. Tap the repository: brew tap ElektraInitiative/homebrew-elektra.
3. If you want to install
   
   
   
   • the bottle use brew install elektra.
   
   
   • release 0.8.19 from source, then use brew install --build-from-source elektra.
   
   
   • the latest version of Elektra, then use brew install --HEAD elektra.
   
   
4. To check if the installation works you can use the command brew test elektra.

It is good if we get some feedback, even if they won't accept it.

Hm, okay. If I have time I will try to open a pull request tomorrow.

This are great news again!

Can you update the README.md of the homebrew-elektra to contain this longer description?

Do you have some build logs of which plugins and bindings are enabled? In particular I would be interested if the python2 bindings are included (and work: can you try to import kdb in a python interpreter)?

Can you update the README.md of the homebrew-elektra to contain this longer description?

Okay, you can take a look at the updated ReadMe here.

Do you have some build logs of which plugins and bindings are enabled?

The list of plugins should be quite extensive, since I installed a lot of the optional Elektra dependencies on my machine. Here is the log produced bybrew install --build-from-source -debug -verbose elektra.

In particular I would be interested if the python2 bindings are included (and work: can you try to import kdb in a python interpreter)?

They should be included (see log above), but nevertheless import kdb reports the following error both in the system version of Python (/usr/bin/python) and in the one installed via Homebrew (/usr/local/bin/python):

import kdb
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named kdb

.

Okay, you can take a look at the updated ReadMe

Great, thank you!

The list of plugins should be quite extensive, since I installed a lot of the optional Elektra dependencies on my machine.

• ronn seems to be missing (so no man pages)
• you do not seem to include any binding (except cpp), seems like you need a -DBINDINGS=ALL
• kdb gen would need python cheetah to work and --install-layout. Seems to be hard to fix (better leave that for now and simply disable gen from TOOLS).

They should be included (see log above)

I think you have mixed up python bindings and plugins, the bindings are not present (no -- Include Binding swig_python2).

• ronn seems to be missing (so no man pages)

It only seems to be missing. I installed ronn via rbenv. It looks like the Homebrew environment uses a different value for PATH which does not include ~/.rbenv/shims. After some research I found a way to add ronn as optional Ruby dependency. In the moment the formula does not recognize my installation of ronn. Hopefully I find a solution for this issue.

• you do not seem to include any binding (except cpp), seems like you need a -DBINDINGS=ALL

You are right, thank you. I added the option to the CMake arguments of the formula.

I think you have mixed up python bindings and plugins, the bindings are not present (no -- Include Binding swig_python2).

You are right again :o). I will check if the bindings work later.

Update

Man Pages

I added ronn as required dependency for the build process here. I do not think that requiring ronn for the build is a problem, since most people will just use the bottled version of the formula anyway.

You may ask why I did not add ronn as optional dependency. The cause of this was the output of brew info, which looks kind of silly and also super wrong if I add the tag :optional:

…
==> Dependencies
Build: cmake ✔
==> Requirements
Build: ronn (ruby module) ✔
Optional: ronn (ruby module) ✔
==> Options
--with-languagemodule
    Build with languagemodule support
…

. The text below shows the current output of brew info elektra:

elektrainitiative/elektra/elektra: stable 0.8.19 (bottled), HEAD
Configuration Framework
https://web.libelektra.org
Not installed
From: https://github.com/ElektraInitiative/homebrew-elektra/blob/master/Formula/elektra.rb
==> Dependencies
Build: cmake ✔
==> Requirements
Build: ronn (ruby module) ✔

.

Bindings

After I add -DBINDINGS=ALL to the CMake options of the formula brew audit --strict elektra shows the following message (after I installed Elektra):

elektrainitiative/elektra/elektra:
  * python modules have explicit framework links
    These python extension modules were linked directly to a Python
    framework binary. They should be linked with -undefined dynamic_lookup
    instead of -lpython or -framework Python.
      /usr/local/Cellar/elektra/0.8.19/lib/python2.7/site-packages/_kdb.so
      /usr/local/Cellar/elektra/0.8.19/lib/python3.5/site-packages/_kdb.so
Error: 1 problem in 1 formula

. If I try import kdb in the Hombrew version of Python, then the Python interpreter crashes, displaying the following error message:

Fatal Python error: PyThreadState_Get: no current thread
fish: '/usr/local/bin/python' terminated by signal SIGABRT (Abort)

This seems to be normal, since ninja test – in my usual build directory – fails too, showing the following errors:

     31 - testpy2_kdb.py (OTHER_FAULT)
     32 - testpy2_key.py (OTHER_FAULT)
     33 - testpy2_keyset.py (OTHER_FAULT)
     34 - test_kdb.py (OTHER_FAULT)
     35 - test_key.py (OTHER_FAULT)
     36 - test_keyset.py (OTHER_FAULT)
     40 - testruby_kdb (OTHER_FAULT)
     41 - testruby_key (OTHER_FAULT)
     42 - testruby_keyset (OTHER_FAULT)

. I used the following command to generate the Ninja project:

    cmake ..                        \
          -GNinja                       \
          -DENABLE_TESTING=ON               \
          -DENABLE_DEBUG=ON                 \
          -DENABLE_LOGGER=OFF               \
          -DBUILD_PDF=ON                    \
          -DCMAKE_EXPORT_COMPILE_COMMANDS=ON        \
          -DPDFLATEX_COMPILER=`which latexmk`       \
          -DPDFLATEX_COMPILER_OPTIONS='-pdf;-f;-quiet'  \
          -DCMAKE_PREFIX_PATH=/usr/local/opt/qt5        \
          -DTOOLS=ALL                   \
          -DBINDINGS=ALL

. The Lua bindings seem to work fine. At least require 'kdb' does not show any error messages.

Thank you for your effort!

Man Pages

Yes, I agree that people will prefer the bottled version. And having no man pages really is a major usability problem, so the requirement is reasonable..

crash of import kdb

@manuelm lm do you have an idea why the bindings crash?

@sanssecours Maybe the swig version is too old, or a wrong swig used?

They should be linked with -undefined dynamic_lookup instead of -lpython or -framework Python.

Maybe we should simply pass -framework in case of APPLE to target_link_libraries. According to cmake docu there seems to be a special treatment for -framework.

Maybe the cmake file for python is broken? Here is a long discussion about broken python cmake files. (Might be unrelated, though) I cannot really help here, the issue is quite Mac OS X specific.

@sanssecours Maybe the swig version is too old…

Nope, I installed the newest version of swig (3.0.10) via Homebrew.

…, or a wrong swig used?

I do not think so. I quick search via locate swig only shows the version installed via Homebrew.

@markus2330 yes it works! thanks a lot for the homebrew formula, @sanssecours :ok_hand:

I did have a small issue, but that might be because sudo make uninstall doesn't cleanly uninstall elektra:

> brew install elektra
==> Installing elektra from elektrainitiative/elektra
==> Downloading https://github.com/ElektraInitiative/homebrew-elektra/releases/download/0.
==> Downloading from https://github-cloud.s3.amazonaws.com/releases/76387201/caf85aac-c307
######################################################################## 100.0%
==> Pouring elektra-0.8.19.sierra.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink share/elektra/test_data/lua/batterytotracker.lua
/usr/local/share/elektra/test_data/lua is not writable.

You can try again using:
  brew link elektra
==> Summary
🍺  /usr/local/Cellar/elektra/0.8.19: 2,668 files, 54.1M

> brew link elektra
Linking /usr/local/Cellar/elektra/0.8.19...
Error: Could not symlink lib/elektra/libelektra-storage.so
Target /usr/local/lib/elektra/libelektra-storage.so
already exists. You may want to remove it:
  rm '/usr/local/lib/elektra/libelektra-storage.so'

To force the link and overwrite all conflicting files:
  brew link --overwrite elektra

To list all files that would be deleted:
  brew link --overwrite --dry-run elektra

After running brew link --overwrite elektra it works perfectly fine, though.

If I try import kdb in the Hombrew version of Python, then the Python interpreter crashes, displaying the following error message:

Fatal Python error: PyThreadState_Get: no current thread
fish: '/usr/local/bin/python' terminated by signal SIGABRT (Abort)

So python -c "import kdb" gives the above fatal error? Sounds weird because the bindings (in contrast to the plugin) don't touch any thread states or interpreters at all.

btw take a look at https://github.com/ElektraInitiative/libelektra/blob/master/.travis.yml#L52

So python -c "import kdb" gives the above fatal error?

Yes, the command /usr/local/bin/python -c "import kdb" prints this error message, if I install Elektra using an old version of the formula. The good news is that /usr/local/bin/python3 -c "import kdb" works.

btw take a look at https://github.com/ElektraInitiative/libelektra/blob/master/.travis.yml#L52

If I add the additional definitions and disable pyenv, then the Python tests - in my usual build directory - run fine. Thank you.

Thank you, great work!

For anyone that is interested: I recently opened a pull request for Elektra 0.8.21 at homebrew-core here.

So great that the homebrew formula got accepted! https://github.com/Homebrew/homebrew-core/pull/22049

A minor thing: In http://brewformulas.org/Elektra the description " A repository for sharing configuration snippets" is a bit wrong, is it possible to modify this via the formula? Or do we need to submit an issue in their tracker to change this text?

I do not think http://brewformulas.org is an official Homebrew site. You can find the correct description of the Formula:

Framework to access config settings in a global key database

at the official Homebrew homepage.

Thank you, seems like the other non-official page with the wrong description got a higher rank in my Internet search. Then there there is no problem about the description from our side.

Thanks again for your tenacity for getting the homebrew formula official.

Can you please update doc/INSTALL.md and clear up when to use the official formula and when to use our tap?

Can you please update doc/INSTALL.md and clear up when to use the official formula…

I already did that in my local version of the repository. Pull request #1777 contains these changes.

…and when to use our tap?

The Readme of our tap already includes this information.

What about keeping this open to track the status of the homebrew formula for every release? If preferred we can also add a new issue for the tracking.

What about keeping this open to track the status of the homebrew formula for every release?

As you already showed by posting here 😊, we do not need to keep this issue open to add new comments.