Install pyqt via homebrew with `--with-python3` but still goes to Python 2 - python-3.x

Here's my command and output (some command line arguments are left out). What is going wrong? Thank you.
$ brew reinstall pyqt --with-python3
==> Reinstalling pyqt --with-python3
==> Downloading http://downloads.sf.net/project/pyqt/PyQt4/PyQt-4.10.3/PyQt-mac-
Already downloaded: /Library/Caches/Homebrew/pyqt-4.10.3.tar.gz
==> Patching
patching file configure.py
==> python configure.py --confirm-license --bindir=/usr/local/Cellar/pyqt/4.10.3
==> python ./configure-ng.py --confirm-license --bindir=/usr/local/Cellar/pyqt/4
==> make
==> make install
==> Caveats
Set PYTHONPATH if you want Python to find your site-packages:
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH
==> Summary
🍺 /usr/local/Cellar/pyqt/4.10.3: 560 files, 18M, built in 6.6 minutes
UPDATE:
I think the formula of pyqt somehow hard-codes the python's version. For example it explicitly includes paths like python2.7/site-packages/. Here's part of the file:
def install
# On Mavericks we want to target libc++, this requires a non default qt makespec
if ENV.compiler == :clang and MacOS.version >= :mavericks
ENV.append "QMAKESPEC", "unsupported/macx-clang-libc++"
end
args = [ "--confirm-license",
"--bindir=#{bin}",
"--destdir=#{lib}/python2.7/site-packages",
"--sipdir=#{share}/sip" ]
# We need to run "configure.py" so that pyqtconfig.py is generated, which
# is needed by PyQWT (and many other PyQt interoperable implementations such
# as the ROS GUI libs). This file is currently needed for generating build
# files appropriate for the qmake spec that was used to build Qt. This method
# is deprecated and will be removed with SIP v5, so we do the actual compile
# using the newer configure-ng.py as recommended.
system "python", "configure.py", *args
(lib/'python2.7/site-packages').install 'pyqtconfig.py'
# On Mavericks we want to target libc++, this requires a non default qt makespec
if ENV.compiler == :clang and MacOS.version >= :mavericks
args << "--spec" << "unsupported/macx-clang-libc++"
end
system "python", "./configure-ng.py", *args
system "make"
system "make", "install"
end

You should check out this issue on Homebrew's git:
https://github.com/Homebrew/homebrew/issues/25735
We can no longer use the --with-python3 argument with pyside/pyqt/sip. Unfortunately, it seems like we can't use Homebrew for these modules in a while. They probably have to find another solution of handling the formulas for having Python 2.7 and Python3 installs first.
I scratched my head for days figuring this out. Ended up with installing PyQt from source.
Good luck.

Related

Issue when installing lablgtk with opam

I'l trying to install a package (https://github.com/SchornacklabSLCU/amfinder) that use opam to install several libraries. However, two libraries failed to install: lablgtk and cairo2-gtk.I tried to install these two directly via opam (opam install labgtk) but got the same error:
User configuration:
~/.profile is already up-to-date.
[NOTE] Make sure that ~/.profile is well sourced in your ~/.bashrc.
[ERROR] There already is an installed switch named 4.08.0
[NOTE] Package camlzip is already installed (current version is 1.11).
[NOTE] Package magic-mime is already installed (current version is 1.2.0).
[NOTE] Package cairo2 is already installed (current version is 0.6.2).
[NOTE] Package odoc is already installed (current version is 2.0.0).
[NOTE] Package dune is already installed (current version is 2.9.1).
The following actions will be performed:
βˆ— install lablgtk 2.18.11
βˆ— install cairo2-gtk 0.6.2
===== βˆ— 2 =====
Do you want to continue? [Y/n] y
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><><><>
⬇ retrieved cairo2-gtk.0.6.2 (cached)
⬇ retrieved lablgtk.2.18.11 (cached)
[ERROR] The compilation of lablgtk.2.18.11 failed at "./configure --prefix /home/alr/.opam/4.08.0
LABLGLDIR=/home/alr/.opam/4.08.0/lib/lablgl".
#=== ERROR while compiling lablgtk.2.18.11 ====================================#
# context 2.1.1 | linux/x86_64 | ocaml-base-compiler.4.08.0 | https://opam.ocaml.org#03fce048
# path ~/.opam/4.08.0/.opam-switch/build/lablgtk.2.18.11
# command ~/.opam/opam-init/hooks/sandbox.sh build ./configure --prefix /home/alr/.opam/4.08.0 LABLGLDIR=/home/alr/.opam/4.08.0/lib/lablgl
# exit-code 1
# env-file ~/.opam/log/lablgtk-16902-8d49b3.env
# output-file ~/.opam/log/lablgtk-16902-8d49b3.out
### output ###
# [...]
# checking native dynlink... checking for pkg-config... /home/linuxbrew/.linuxbrew/bin/pkg-config
# checking for GTK+ - version >= 2.0.0...
# *** 'pkg-config --modversion gtk+-2.0' returned 2.24.33, but GTK+ (2.24.32)
# *** was found! If pkg-config was correct, then it is best
# *** to remove the old version of GTK+. You may also be able to fix the error
# *** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
# *** /etc/ld.so.conf. Make sure you have run ldconfig if that is
# *** required on your system.
# *** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH
# *** to point to the correct configuration files
# no
# configure: error: GTK+ is required
<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
β”Œβ”€ The following actions failed
β”‚ Ξ» build lablgtk 2.18.11
└─
╢─ No changes have been performed
<><> lablgtk.2.18.11 troubleshooting ><><><><><><><><><><><><><><><><><><><><><>
=> This package requires gtk+ 2.0 development packages installed on your system
File "dune", line 4, characters 29-39:
4 | (libraries lablgtk2 cairo2 cairo2-gtk camlzip magic-mime)
^^^^^^^^^^
Error: Library "cairo2-gtk" not found.
pkg-config --modversion gtk+-2.0returns 2.24.33
echo $LD_LIBRARY_PATHreturns empty path.
echo $PKG_CONFIG_PATHreturns /home/alr/.opam/4.08.0/lib/pkgconfig:
File /etc/ld.so.conf contains the following line: include /etc/ld.so.conf.d/*.conf
I am using WSL2 on Windows10 with Ubuntu18.04. libgtk2.0-dev is already installed.
I guess there is an error in path to library but cannot figure out how to solve it.
Any help would be greatly appreciated.
Thanks

How do you import a Haskell module that was installed using Cabal?

I installed the timezone-series Haskell module using cabal install timezone-series-0.1.5.1.
I then defined a module named Main.hs that starts with:
import Data.Time.LocalTime.TimeZone.Series -- from timezone-series-0.1.5.1
when I run ghc Main.hs, GHC throws the following error:
/home/ubuntu/Main.hs:2:1: error:
Failed to load interface for β€˜Data.Time.LocalTime.TimeZone.Olson’
I tried explicitly including the cabal directory in GHC's search path using:
ghc -i/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/ Main.hs
This resulted in the correct path being searched, but GHC is only looking for files ending in the suffix ".hs":
Locations searched:
...
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hsig
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhsig
Cabal installed interface files instead however:
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Olson.hi
From line 318 of GHC's source code it looks like GHC ignores "*.hi" files unless it is called in single-shot mode (with the -c flag). Is this correct? (See: https://github.com/ghc/ghc/blob/67a5a91ef5e61f3b3c84481d8a396ed48cd5d96e/compiler/GHC/Unit/Finder.hs)
How can I get GHC to import this module?
An help will be greatly appreciated!
My suggested ways of installing packages in order of my preference:
Make a cabal package and add timezone-series you want to install to the build-depends field as described in the cabal manual.
Use the experimental cabal-env tool to basically automate the process of point 3 below, but then with the global environment. This makes a new build-plan every time you install a new package, so it is like removing the package environment and building it again with all the old packages and the new package added to it. You can add specific constraints like this: cabal-env "timezone-series == 0.1.5.1".
Install a package into local package environment with cabal --package-env . --lib timezone-series. You can add as many packages as you want after the --lib option to install more than one package. If you later want to use a different set of packages simply remove the .ghc.environment.* file that is generated and rerun the installation with a new set of packages. GHC will automatically use these package environment files that are in the current or parent directories. You can specify specific constraints with the --constraint option like this: --constraint "timezone-series == 0.1.5.1".
Use cabal install --lib timezone-series to install it directly into the global environment (~/.ghc/x86_64-linux-8.0.2/environments/default), this will fail if a conflicting package was installed earlier. When you run into errors you can remove that package environment and try again.
Finally, I want to note that GHC 8.0.2 is quite old, so I would advise you to upgrade if you don't have a specific reason for using that version.

How to build pyodbc with links to iODBC in macOS?

In Driver for pyodbc: how to specify its location in macOS?, TallTed suggested to open question to explain the following
Build pyodbc with links to iODBC (not its default of UnixODBC, which is not typical for macOS).
so now with the focus β€”
How can I build pyodbc with links to iODBC (not its default of UnixODBC, which is not typical for macOS)?
This should/might work in 4.0.23, as it was the way it was done up to pyodbc v3.0.7:
First, in the file setup.py, change line 165 from --
settings['libraries'].append('odbc')
-- to --
settings['libraries'].append('iodbc')
Second, disable/delete lines 178, 179, and 183.
# Add directories for MacPorts and Homebrew.
# dirs = ['/usr/local/include', '/opt/local/include','~/homebrew/include']
# settings['include_dirs'].extend(dir for dir in dirs if isdir(dir))
# unixODBC make/install places libodbc.dylib in /usr/local/lib/ by default
# ( also OS/X since El Capitan prevents /usr/lib from being accessed )
# settings['library_dirs'] = [ '/usr/local/lib' ]
For reference, see the file setup.py as of pyodbc 3.0.7, starting at line 146
Note: This will use the macos system supplied -- and presumably outdated -- libiodbc.dylib in /usr/lib. Not sure where the iODBC Framework installs the iODBC files, though. Maybe TallTed can comment on this?

Pypi package : where is my executable?

(Archlinux/Python3.5)
I'm working on a small Python3 project made up of only one Python file . With the help of tutorials like this one, I've created a Pypi package with the following commands :
$ python setup.py sdist bdist_wheel register -r pypi (ok, no error msg)
$ python setup.py sdist bdist_wheel upload -r pypi (ok, no error msg)
... and I thought I would juste have to write :
$ sudo pip install katal (ok, no error msg)
and then, e.g. :
$ katal --version
... in order to use it.
But the last command fails : there's no katal or Katal command; if I take a look at /usr/lib/Python3.5/site-packages/ , I only see the following files (no .py file have been installed !) :
/usr/lib/python3.5/site-packages/Katal-0.0.9.dist-info/DESCRIPTION.rst
/usr/lib/python3.5/site-packages/Katal-0.0.9.dist-info/METADATA
/usr/lib/python3.5/site-packages/Katal-0.0.9.dist-info/RECORD
/usr/lib/python3.5/site-packages/Katal-0.0.9.dist-info/WHEEL
/usr/lib/python3.5/site-packages/Katal-0.0.9.dist-info/metadata.json
/usr/lib/python3.5/site-packages/Katal-0.0.9.dist-info/top_level.txt
I've obviously forgotten something... But what ? My setup.py clearly defines where is the unique package of my project (=take everything but the test directory, including the katal sub-directory) :
packages=find_packages(exclude=['tests*']),
Any help would be appreciated !
in your setup.py, there is a section which is commented out:
...
##entry_points={
## 'console_scripts': [
## 'sample=sample:main',
## ],
##
...
This is where I would normally define an executable, please see this tutorial. You can also define a scripts argument to setup which works a little differently (and might match your use case a little better), but that is covered in the tutorial I linked to.

How to check for haskell package versions in ./configure?

how can I tell configure to check for version >= x.y of a given Haskell package?
Thanks,
Use cabalvchk: http://hackage.haskell.org/package/cabalvchk-0.2
For example, to verify that the version of parsec is >= 0.4, you could issue:
$ cabalvchk parsec '>= 0.4'
The return code will be zero if the version constraint is satisfied and non-zero otherwise. The version constraint can be anything cabal understands. An optional third parameter can be non-blank to request verbose output.
I don't know much about configure; can you ask it to run a particular command? If so, then ghc-pkg latest should help you out. For example, here's a run on my machine for the zlib package:
% ghc-pkg latest zlib
zlib-0.5.3.1
% ghc-pkg latest --global zlib
zlib-0.5.3.1
% ghc-pkg latest --user zlib
ghc-pkg: cannot find package zlib
zsh: exit 1 ghc-pkg latest --user zlib
The --global should be used for system-wide installations, and no flag at all for user-specific installations. The --user flag should only be used when you want to check whether a user has a local installation of a package (that may override the global one).
Unless you have a reason not to, I recommend ditching configure in favor of cabal. For cabal, the solution here is to first cabal init in your project's directory, then check that you have a line like this in the .cabal file that's created:
build-depends: zlib >= 0.5
The cabal toolchain is the standard for Haskell projects (because it automates and simplifies many things, including dependency-chasing). You can also ask cabal to invoke configure if there are other dependencies. Open a separate question if you'd like more information about this.
Perhaps the better question is: should you? Checking for a specific version number is one of the great arguments in the autoconf world, and the general winner of the debate is the side which says you should never do it. What specific feature of Haskell do you need? Test for that. As a simple example (unrelated to haskell), suppose your program uses inotify so you want the configury to test if it is available. You could just test if the kernel version is > 2.6.13, but then when Joe tries to build your program on his 2.4.xx version in which he has patched in inotify capability, he's going to be really irritated that your program won't work.
You do not care if Haskell > x.y is available. Instead, there is some specific feature of Haskell that you want that was introduced in x.y; test for that feature.
Using ghc-pkg list, you can get a list of installed versions of a package in ascending order. You should hopefully be able to filter through this list looking for a match. (I don't know how to do this with configure, sorry).
$ ghc-pkg list yesod
/home/ahammar/.haskell/lib/ghc-7.0.2/package.conf.d
/home/ahammar/.ghc/x86_64-linux-7.0.2/package.conf.d
yesod-0.8.2.1
yesod-0.9.1
yesod-0.9.2.2
Try something like this:
# Find ghc-pkg, so we can do version checks
AC_ARG_VAR([GHC_PKG], [Path to ghc-pkg])
AC_PATH_PROG([GHC_PKG], [ghc-pkg])
AS_IF([test -z "$GHC_PKG"], [AC_MSG_ERROR([Cannot find ghc-pkg.])])
# Check that the package actually exists
AC_MSG_CHECKING([for Haskell package foo])
AS_IF([$GHC_PKG latest foo > /dev/null 2>&1],
[AC_MSG_RESULT([yes])],
[AC_MSG_RESULT([no])
AC_MSG_ERROR([Cannot find foo])])
# Check its version
AC_MSG_CHECKING([if foo is new enough])
foo_ver=`$GHC_PKG latest foo | sed 's/^foo-//'`
# At this point you have the version of foo and the minimum version you want.
# The rest of the test is pretty easy to write, use cut and test to compare the
# version numbers. If it's new enough, AC_MSG_RESULT([yes]).
# If not, AC_MSG_RESULT([no]) and AC_MSG_ERROR([foo is not new enough.])

Resources