I am trying to package the ffvideo module for conda. It is a Cython module that links into ffmpeg. I am able to build the recipe (so the linking works at compile time), however I cannot install the resulting package in a new environment. The reason is that at execution time the package cannot find the dlls it was linked to at compile time (their path is now different, because they are in a different environment).
I tried using the binary_has_prefix_files flag in the conda recipe, which I point to Lib\site-packages\ffvideo.pyd. However, it does not seem to help.
Is there a way to link Cython packages to relative paths or something like that?
The recipe is at the moment:
package:
name: ffvideo
version: 0.0.13
source:
fn: b45143f755ac.zip
url: https://bitbucket.org/groakat/ffvideo/get/b45143f755ac.zip
# md5: cf42c695fab68116af2c8ef816fca0d9
build: [win]
number: 3 [win]
binary_has_prefix_files:
- Lib\site-packages\ffvideo.pyd
requirements:
build:
- python
- cython [win]
- mingw [win]
- ffmpeg-dev [win]
- mingw
- pywin32
- setuptools
- libpython
run:
- python
- ffmpeg-dev [win]
- cython
- mingw
- pywin32
- setuptools
- libpython
about:
home: https://bitbucket.org/groakat/ffvideo/
license: Standard PIL license
The package is on binstar https://binstar.org/groakat/ffvideo/files . The dependencies are all in my channel https://binstar.org/groakat/
One more thought. As ffvideo depends on ffmpeg-dev which I also packaged, might it be that I need to use the binary_has_prefix_files option there as well?
To quote Travis Oliphant's answer from the conda mailing list:
On Windows, our current recommended approach is to:
1) put the DLLS next to the executable that needs them
2) put the DLLS in a directory that is on your PATH environment variable.
By default, Anaconda and Miniconda add two directories to the path
(the root directory and %ROOT% / Scripts). You could either put the
dlls in that directory or add the directory the dlls are located to
your PATH.
Related
I have a conflict while attempting a conda build:
Package python_abi conflicts for:
pyibis-ami[version='>=4.0.5'] -> click -> python_abi[version='3.10.*|3.8.*|3.11.*',build='*_cp311|*_cp310|*_cp38']
{snip}
pyibis-ami[version='>=4.0.5'] -> python_abi=3.9[build=*_cp39]
There's clearly a conflict: click doesn't support 3.9, but pyibis-ami demands it.
But, click is a dependency of pyibis-ami.
And I just successfully built pyibis-ami, before attempting this build!
(It's a direct dependency of the package I'm trying to build now.)
So, how did I succeed at building pyibis-ami?!
Why didn't the same conflict block that build?
Some additional sleuthing:
The pyibis-ami package does not call for any specific version of click.
Looking at what's available for the most recent version of click (8.1.3), I find:
one noarch build w/ dependency: __unix,
one noarch build w/ dependency: __win, and
several osx-arm64 (the platform I'm working on) builds, all dependent upon a specific (different) Python minor version, for instance:
dependencies:
- python >=3.9,<3.10.0a0
- python >=3.9,<3.10.0a0 *_cpython
- python_abi 3.9.* *_cp39
(There are similar builds for: 3.8, 3.10, and 3.11.)
Now, I'm giving the --python=3.9 option in my conda build ... command, but I have noticed cases in which Python v3.8 gets selected for the temporary build virtual environment, despite that --python=3.9 command line option.
And I'm wondering if that's what's happening here.
Two questions:
Where can I find the log file for my last build attempt, in order to see which version of Python was actually selected for the conda build ... virtual environment?
What things are allowed to override the --python=3.9 command line option?
I am importing a project to read the docs; I have a series of git tags representing older versions of the library; which I would like to have docs generated for those versions as well. The problem is that there is no .readthedocs.yaml file in the repo when that tag was placed.
Normally in this case I would put some of the relevant settings in web interface, which clearly states those settings would be ignored with the presence of a .readthedocs.yaml file; but my config file does have a pre_build task
version: 2
build:
os: "ubuntu-22.04"
tools:
python: "3.10"
jobs:
pre_build:
- doxygen ./doc/doxygen/doxygen.conf
sphinx:
builder: html
configuration: doc/conf.py
python:
install:
- requirements: doc/requirements.txt
Is there a way I can build documentation for past git tags using the "current" config file?
I just installed FPC 3.2.0 (on Linux Mint 19.3) and trying to use FPC IDE. I launched the IDE from the bin installation subfolder as ./fp, written a simplest program in IDE
program hello;
begin
writeln('hello');
end.
saved the program as hello.pas and when I compile it I get
(3,1) Fatal: Can't find unit system used by hello
(0) Fatal: Compilation aborted
This is strange because system is the compiler's unit, not a user's unit.
I tried to google the issue, found several posts in different forums, one question was dated back to 2007 year, and none of the questions was answered.
Is where a way to solve the issue or FPC IDE is dead for about 15 years?
Check the unit directories in options->directories -> unit directories.
The package configuration should have put a line like
/usr/lib/fpc/$FPCVERSION/units/$FPCTARGET/*
The dollar values are builtins (respectively 3.2.0 and i386-linux or x86_64-linux). Please verify that the directories with prebuilt .ppu .o are there.
Try to fix your installation of FPC or you can fix it manually by calling fpcmkcfg
fpcmkcfg -d "basepath=path/to/fpc/3.3" -o path/to/fpc.cfg
For instance, if the compiler is in /usr/local/bin, it will look in
/usr/local/etc.
Had the same problem on Ubuntu 20.04. To solve it, I had to create the file fp.cfg in my project's folder with the following content:
-Fu/usr/lib/x86_64-linux-gnu/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/x86_64-linux-gnu/fpc/$fpcversion/units/$fpctarget/*
If this will not work, it means unit path on your system is different. You may use something like
dpkg -L fp-units-base-3.0.4 | grep .ppu
to find out where units are actually stored. Replace 3.0.4 with your actual Free Pascal version. If you do not know exact version, use
sudo apt install apt-show-versions
apt-show-versions fpc
It will show something like
fpc:all/focal 3.0.4+dfsg-23 uptodate
3.0.4 is the version number you need.
Another way of getting needed paths is running this command:
cat /etc/fpc.cfg | grep -- -Fu | head -2
So you may just run
cat /etc/fpc.cfg | grep -- -Fu | head -2 > fp.cfg
in your project's folder to have the problem solved.
How to use Free Pascal (Lazarus) on Linux - no install solution:
If not already installed, install "GNU binutils" (sudo apt-get install binutils)
Dowload the latest version of Free Pascal (Lazarus): from the Downloads section of the Lazarus Home page (Lazarus is a professional open-source cross platform IDE powered by Free Pascal):
2.1. In case of a Debian based Linux system (such as Ubuntu): the .deb package could be downloaded ("fpc-laz_<version> ... .deb" (replace <version> with an actual version number))
2.2. In case of a RPM based Linux system (such as Fedora): the .rpm package could be downloaded ("fpc-<version> ... .rpm" (replace <version> with an actual version number))
Extract the downloaded package:
3.1. Place the downloaded .deb / .rpm package in the folder where you are going to extract it
3.2. Extract the downloaded .deb / .rpm package by Right-Click-ing it and then choosing Extract Here
3.3. Rename the extracted folder, as you desire, for example "fpc"; Further we denote this folder as "<BASEFOLDER>" and its path as - "<BASEFOLDER_PATH>"
In the case of a .deb package: Open the extracted <BASEFOLDER> and then, extract "data.tar.xz" - by Right-Click-ing it and then choosing Extract Here
Launch the Free Pascal window by typing the next command in the terminal - this command may vary according to the terminal used - replace <terminal> with the terminal used (by default: for Gnome based Desktop Environments -> gnome-terminal; for KDE based Desktop Environments -> konsole; for Xfce based Desktop Environments -> xfce4-terminal; for the MATE Desktop Environment -> mate-terminal; ...):
<terminal> -e '<BASEFOLDER_PATH>/usr/bin/fp'
OR:
<terminal> -- '<BASEFOLDER_PATH>/usr/bin/fp'
To add the units folders: From the Free Pascal Menu, access: Options -> Directories -> and copy (CTRL + C to Copy from outside the IDE, and (FN + )SHIFT + Insert to Paste inside the IDE) to the "Units" tab, the next three lines, each on a new line (replace <BASEFOLDER_PATH> with its corresponding value, and replace <LIB_FOLDER> with: lib in case of a .deb package or lib64 in case of a .rpm package):
<BASEFOLDER_PATH>/usr/<LIB_FOLDER>/fpc/$fpcversion\units\$fpctarget
<BASEFOLDER_PATH>/usr/<LIB_FOLDER>/fpc/$fpcversion\units\$fpctarget\*
<BASEFOLDER_PATH>/usr/<LIB_FOLDER>/fpc/$fpcversion\units\$fpctarget\rtl
Please note that by moving the files from the <BASEFOLDER> directory to other <BASEFOLDER_PATH>, you'll have to update the above three lines so that they contain the new <BASEFOLDER_PATH>, otherwise you might get errors like:
"Fatal: Can't find unit ..."
For navigation inside the IDE using keyboard - the following shortcuts can be used: Alt + Highlighted-letter, Highlighted-letter(s), Tab / Shift + Tab, Arrows, Enter, Esc
For Official Online Documentation see:
Online Documentation
The solution to similar issues on Github about this all point to installing MkDocs or the theme with a package manager and not pip. However, I have installed both with pip.
Installed MkDocs with pip (not a package manager)
Installed n number of MkDocs themes with pip
updated mkdocs.yaml to add:
theme:
name: '{name_of_theme}'
then
mkdocs serve
result
ERROR - Config value: 'theme'. Error: Unrecognised theme name: '{name_of_theme}'. The available installed themes are: mkdocs, readthedocs
What am I missing?
In your mkdocs.yaml, use:
theme:
name: mkdocs
or
theme:
name: readthedocs
Essentially, the name of a theme you actually installed.
Had the same problem with mkdocs-material. In my case this originated from a faulty installation of the theme. From the mkdocs-material FAQ:
Check if mkdoc is correctly installed: mkdocs --version. You should get the version and installed path back.
Check if the theme is correctly installed: mkdocs serve --help. You should get a list of parameters. Check this entry if you theme name appears:
-t, --theme [material|mkdocs|readthedocs] (in this case "material")
If your theme name is missing, try reinstalling it. In my case, I had used the python -m pip flag with mkdocs and needed to do the same with the theme:
python -m pip install mkdocs
python -m pip install mkdocs-material
It could be that you have another version of mkdocs globally installed. That was my case.
I have recently begun using nala, a wrapper for apt, the package manager for the Debian family of Linux (I'm using Pop!_OS, a variant of Ubuntu). And it has a requirement for mkdocs from the distribution's repos, which I just realized.
When I typed mkdocs in the terminal, the wrong copy would be launched - the one in /usr/bin (actually in /usr/lib/python3/dist-packages/ according to mkdocs --version) instead of the one in my virtual environment. It's curious, because the virtual environment's bin folder was supposed to have priority in the PATH.
I uninstalled nala, which removed the globally installed mkdocs, and of course that fixed the problem, but I really like nala. I reinstalled it, and after reinstallation, the problem did not return. (Which does not make much sense to me.)
Next time, I will try to deactivate my virtual environment, then reactivate it to see if it fixes the problem. Or else I could check the path for the locally installed mkdocs (from the virtual environment) with which -a mkdocs and use its full path.
I've never seen the yaml file with the extension ".yaml".
Have you tried changing it to ".yml", so it's "mkdocs.yml".
You can definitely install mkdocs and a theme with pip.
I'm trying to automatically import a project from Github into ReadtheDocs. When creating the documentation it is failing due to a missing dependency. I've tried adding the setup.py installation in the config, but am running into the following:
Problem in your project's configuration. Invalid "python.install.0": .readthedocs.yml: "path" or "requirements" key is required
Current Configuration yaml:
# Required
version: 2
# Build documentation in the docs/ directory with Sphinx
sphinx:
configuration: docs/conf.py
# Optionally build your docs in additional formats such as PDF and ePub
formats: all
# Optionally set the version of Python and requirements required to build your docs
python:
version: 3.6
install:
- method: setuptools
- path: .
I wasn't able to find an answer that leverage the pre-existing setup.py file, but was able to get it working with a requirements.txt file. The relevant portion is the install portion of the python section in the readthedocs.yml file (seen below).
Inside the requirements.txt file I simply copied the install requirements section from the setup.py.
# Required
version: 2
# Build documentation in the docs/ directory with Sphinx
sphinx:
configuration: docs/conf.py
# Optionally build your docs in additional formats such as PDF and ePub
formats: all
# Optionally set the version of Python and requirements required to build your docs
python:
version: 3.6
install:
- requirements: docs/requirements.txt
I also had this issue just now, and eventually figured out that the YAML declaration is wrong. It should not be:
python:
version: 3.6
install:
- method: setuptools
- path: .
This defines two entries in python.install, the first one containing only the method key set to setuptools, and the second one containing only the path key set to .. They have nothing to do with each other semantically, and so readthedocs complains about the first entry missing that path key. Instead, use:
python:
version: 3.6
install:
- method: setuptools
path: .
This now defines python.install to be a list with exactly one entry, python.install.0, that has both required keys. And so readthedocs started accepting my config after I did this one-character deletion.
Yet another example of YAML being less intuitive than one would like.