(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.
Related
I have an old c++/python project that includes a python zip file "python27.zip". This zip file contains pyo optimized files.
I am trying to update python from 2.7 to the latest 3.7.1 (also updated the *.so lib file)
I did the next steps:
./configure --enable-shared --prefix=~/python-3.7.1/dist
make
sudo make install
I see that I have ~/python-3.7.1/dist/lib/python3.7 and it's structure is close to that I have in my old 2.7 zip.
Next I try to compile all the folder into pyo like:
python3.7 -O -m compileall .
It tells me that it requires Lib and Include (the headers) so I copied those 2 folders in that location too.
Doing python3.7 -O -m compileall . again inside dist/lib/python3.7 shows me
Listing './Lib/site-packages'...
Listing './Lib/sqlite3'...
....
and some errors like:
Compiling './Lib/test/badsyntax_future10.py'...
*** File "./Lib/test/badsyntax_future10.py", line 3
from __future__ import print_function
^
SyntaxError: from __future__ imports must occur at the beginning of the file
I don't see any pyo's inside. Also if I try to do the same against 1 file, like python3.7 -O token.py (no errors) and also no pyo inside.
Don't judge me strict, I agree that I can be wrong in understanding this compilation process.
I had to create my own tool since I had not found anything suitable for the compilation of all python modules into one location/archive.
This PY_COMPILE_HELPER is available on the github. It was tested only from ubuntu.
With this module you can:
Set input and output folder for the compilation
Output source will have the same structure as the input source
Set optimization level for binary files
Skip or include test modules
Compress compiled files into one archive
Clean previously compiled files from the cache
Usage example:
$ ./py_compile_helper.py ./Python-3.7.1/Lib ./out -z -c -o2
I installed the SourceGraph package using cabal:
cabal install SourceGraph
It was installed perfectly without any errors.
Now, I've created a file called Test.hs to test if I am able to import this package and use it. These are the contents of Test.hs:
module Test where
import SourceGraph
main = putStrLn "Hello World!"
When I do ghc Test I get the following error:
Could not find the module 'SourceGraph'
When I do ghc-pkg list I cannot find SourceGraph in the list, though all dependencies installed along with it are visible.
I checked in C:\Users\MyName\AppData\Roaming\cabal\packages\hackage.haskell.org and I can see the SourceGraph folder there.
But there is no .conf file for SourceGraph in C:\Users\MyName\AppData\Roaming\ghc\x86_64-mingw32-7.10.2\package.conf.d.
Also, all the .log files in C:\Users\MyName\AppData\Roaming\cabal\logs have a line In-place registering packagename-version... at the end, but SourceGraph-0.7.0.7,log doesn't.
Help please?
[System Specifications: GHCi version 7.10.2, Cabal Version: 1.22.4.0, OS: Windows 8 Pro, Processor: Intel Core i5 (64 bit)]
SourceGraph is not a library, it is a program to be run on the command line.
See it's hackage page
There it says (with added $s for the bash prompt):
To use SourceGraph, call it as either:
$ SourceGraph path/to/Foo.cabal
Or, if your project doesn't use Cabal, then there is limited support for > using an overall module from your program/library:
$ SourceGraph path/to/Foo.hs
I have a package named commands. I want to install it into its own sandbox e.g. .cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d/commands-0.0.0-f3f84f48f42ac74a69ee5fd73512bfd0.conf. currently, there is just one .hi interface file for one module Commands, I don't know how it got there.
I tried cabal install commands, by the logic of "that's how the other packages got there I think", but it fails with unknown package.
I also tried stuff with ghc-pkg like ghc-pkg update commands -f .cabal-sandbox/x86_64-osx-ghc-7.8.3-packages.conf.d but I'm not using them right. ideally, I'd like to do this with cabal.
the last thing I tried was ghc -idist/build/, but it complained about the package names in the interface files being different, command versus main ("... differs from name found in the interface file ..."). and if I faked the executable's package with ghc -package-name commands-0.0.0, the linker complained that it couldn't find the symbol _ZCMain_main_closure, because every executable needs the function main in the module Main in the package main.
I'm sure there's a better way of doing this.
I followed online examples for my cabal file:
$ cat commands.cabal
name: commands
library
exposed-modules: Commands.Types, Commands.Bits
...
the minimal failing code example is just:
$ cat Main.hs
import Commands.Types
main = return ()
in the root project directory.
Context: I need to build my executable with make (not cabal) because it links to foreign code (Objective-C via language-c-inline). my makefile: https://github.com/sboosali/Haskell-DragonNaturallySpeaking/blob/master/Makefile). thus, I have to compile a script explicitly. I don't know how to compile the executable with cabal, but I want cabal to build and test and manage my library.
By putting my package into the sandbox, I will be able to import its modules from the script, by compiling with cabal exec -- ghc. I will also be able to include the script with extra-source-files at least, and know it will work.
Here's what I'd try:
First unregister any previous commands library. Try
ghc-pkg --global unregister commands
Install new commands to your sandbox.
From your sandbox directory, try this:
cabal --enable-shared --disable-documentation --prefix=./ install /path/to/your/library/source
Note the prefix specification.
I nuked it (rm -fr .cabal-sandbox/), reinstalled everything (cabal install --only-dependencies), added itself as a source (cabal sandbox add-source .), installed it (cabal install command). and then make worked. idk...
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.
Is there an easy way to install SCons as an egg using zc.buildout? My initial thought was that since it uses distutils I would be able to install it using zc.recipe.egg and thought that the egg would be set up in such a way that the SCons scripts go to ${buildout:directory}/bin and SCons gets added to the PYTHONPATH.
[buildout]
parts =
python
[python]
recipe = zc.recipe.egg
interpreter = mython
eggs =
SCons == 2.0.1
Unfortunately, I don't think SCons' setup.py is written in such a way that it works well with zc.recipe.egg. I end up with:
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/scons-2.0.1/
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/scons-2.0.1/SCons/
${buildout:directory}/eggs/scons-2.0.1-py2.6.egg/EGG-INFO/scripts/
This would work if (2) were on PYTHONPATH and the contents of (4) were copied or linked to the bin directory.
Ideally, I would like to install this as an egg to make use of my global eggs-directory; I don't want to have several copies of the same build tool. Is it possible to accomplish this goal using existing recipes, or should I write my own recipe?
EDIT: I made a personal copy and modified SCons' setup.py arguments so that a scons entry point will be created. The only changes I made: remove 'cmdclass', add 'entry_points'.
arguments = {
'name' : "scons",
...
'scripts' : scripts,
'entry_points' : {
'console_scripts':
['scons = SCons.Script:main']
}
}
This kind of works. It gives me a scons script in bin/scons, but not sconsign, scons-time, or scons.bat. I put it in a tar in /var/www/eggs and serve it with apache.
[buildout]
parts =
python
[python]
recipe = zc.recipe.egg:scripts
interpreter = mython
eggs =
scons == 2.0.1
find-links =
http://localhost/eggs/
Not sure if I want to continue in this direction.
Oh my. I looked into the setup.py for SCons, and it is a bit of a mess. It even stubbornly only installs in /usr/local when installing on a Mac. It certainly is not suitable for use with setuptools (and thus zc.buildout).
You can use zc.recipe.command to run the setup.py script with ${buildout:executable} setup.py and configure it to install in a parts subdir, then use a separate part to symlink all the scripts into bin/:
[buildout]
parts = scons
[scons-download]
recipe = gocept.download
url = http://prdownloads.sourceforge.net/scons/scons-2.0.1.tar.gz
md5sum = beca648b894cdbf85383fffc79516d18
[scons-install]
recipe = plone.recipe.command
command = ${buildout:executable} ${scons-download:location}/setup.py install --prefix=${buildout:parts-directory}/scons-install
location = ${buildout:parts-directory}/scons-install
[scons]
recipe = cns.recipe.symlink
symlink =
scons
scons-time
sconsign
symlink_base = ${scons-install:location}/bin
symlink_target = ${buildout:bin-directory}
So, we ignore setuptools altogether, do not build an egg, but instead just download the tarball, run setup.py manually, then symlink the interesting parts.