When I first ran conda-build myrecipe the tar.bz2 had the name 'mypackage-version-py38_0.tar.bz2' however every time I have run it since, the build string is 'mypackage-version-py38head00f5_0.tar.bz2'. Why is 'head00f5' now being added to the build string?
Here is my meta.yaml
package:
name: mypackage
version: "0.0.0.dev1"
source:
path: ../
build:
number: 0
requirements:
build:
- python
- setuptools
- numpy
run:
- python
- numpy
test:
imports:
- mypackage
``
Since version 3.0, conda-build has been adding hashes to the build string. See Differentiating packages built with different variants for more details.
The hash always starts with h and then has 7 hexadecimal numbers. In your particular case it happens to produce the word head, which I'm guessing is part of the confusion. I think that's just a coincidence.
Related
I am trying to use the library pdf2image in a Code Repository on Palantir Foundry and getting the error
pdf2image.exceptions.PDFInfoNotInstalledError: Unable to get page count. Is poppler installed and in PATH?
when using the function convert_from_bytes.
Does anyone know how to reference the poppler path and get rid of this error?
Thanks!
Here is the code:
def extract_pdf_text(input_bytes, language='eng', dpi=200):
pages = convert_from_bytes(input_bytes, dpi)
pdf_pages = ''
for page_index, page in enumerate(pages):
pdf_page = pytesseract.image_to_string(page, lang=language)
pdf_pages = pdf_pages + pdf_page
return pdf_pages
And the meta.yaml for reference:
# If you need to modify the runtime requirements for your package,
# update the 'requirements.run' section in this file
package:
name: "{{ PACKAGE_NAME }}"
version: "{{ PACKAGE_VERSION }}"
source:
path: ../src
requirements:
# Tools required to build the package. These packages are run on the build system and include
# things such as revision control systems (Git, SVN) make tools (GNU make, Autotool, CMake) and
# compilers (real cross, pseudo-cross, or native when not cross-compiling), and any source pre-processors.
# https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#build
build:
- python 3.8.*
- setuptools
# Packages required to run the package. These are the dependencies that are installed automatically
# whenever the package is installed.
# https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#run
run:
- python 3.8.*
- transforms {{ PYTHON_TRANSFORMS_VERSION }}
- transforms-expectations
- transforms-verbs
- pytesseract
- pdfplumber
- googletrans
- regex
- pdf2image
- langdetect
- pandas
- numpy
- selenium
- requests
- pypdf2
- poppler
build:
script: python setup.py install --single-version-externally-managed --record=record.txt
I found the problem when inspecting the CI-Checks. They failed before poppler was pulled. After I cleaned up meta.yaml and the checks succeded everything seems to work fine.
I'm trying to run Packer (1.7) in an Azure DevOps pipeline.
The pkr.hcl files passes validation on my PC running Packer 1.7.3. The pipeline runs Packer 1.7.2.
The YAML task in the pipeline reads like this:
- task: PackerBuild#1
inputs:
templateType: 'custom'
customTemplateLocation: 'ComboBoxes.pkr.hcl'
imageUri: 'ssi-dev-combobox'
imageId: <full resource ID>
When run in the pipeline it reads:
Current installed packer version is 1.7.2.
Running packer fix command
/usr/local/bin/packer fix -validate=false /home/vsts/work/1/s/ComboBoxes.pkr.hcl
Error parsing template: invalid character '#' looking for beginning of value
##[error]Packer fix command failed with error : ''. This could happen if task does not support packer version.
The # is the first character in the .pkr.hcl file. And changing the beginning of the file will change what character shows up as invalid.
Why is it trying to run "packer fix" instead of "packer build"?
So it turns out that the Packer task in Azure Pipelines doesn't work with current versions of Packer.
Run Packer as part of a script task instead.
- task: PowerShell#2
displayName: 'Packer build'
inputs:
targetType: 'inline'
script: 'packer build $(build.artifactstagingdirectory)/ComboBoxes.pkr.hcl'
I am trying to install the DLDT package on Ubuntu 18.04 running on the Raspberry Pi 4. The 2019 branch of DLDT seems to install correctly with some issues but can be rectified. However, the later version (i.e. 2020.3) is giving me the below error:
Error compiling Cython file:
------------------------------------------------------------
...
# Usage example:\n
# ```python
# ie = IECore()
# net = ie.read_network(model=path_to_xml_file, weights=path_to_bin_file)
# ```
cpdef IENetwork read_network(self, model: [str, bytes], weights: [str, bytes] = "", init_from_buffer: bool = "False"):
^
------------------------------------------------------------
/home/ubuntu/dldt/inference-engine/ie_bridges/python/src/openvino/inference_engine/ie_api.pyx:136:10: Signature not compatible with previous declaration
Error compiling Cython file:
------------------------------------------------------------
...
cdef class LayersStatsMap(dict):
cdef C.IENetwork net_impl
cdef class IECore:
cdef C.IECore impl
cpdef IENetwork read_network(self, model : [str, bytes], weights : [str, bytes] = ?, bool init_from_buffer = ?)
^
------------------------------------------------------------
The CMAKE command I use is:
sudo cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_MKL_DNN=OFF -DENABLE_CLDNN=OFF -DENABLE_GNA=OFF -DENABLE_SSE42=OFF -DTHREADING=SEQ -DENABLE_OPENCV=OFF -DENABLE_PYTHON=ON -DPYTHON_EXECUTABLE=/usr/bin/python3.6 -DPYTHON_LIBRARY=/usr/lib/aarch64-linux-gnu/libpython3.6m.so -DPYTHON_INCLUDE_DIR=/usr/include/python3.6 ..
It seems like there is an issue with the declaration of the function or the usage of it. Is there any advice on this from anybody?
Is this a compatibility issue? Is this related to some Cython version issues? The one I have is: 0.29.21
Would appreciate some help on this. Thanks in advance!
Well it turns out that I had two versions of cython on my RPi (i.e. 0.26 and 0.29) and the cmake was using the older version. Once I updated the cmake to use the 0.29 version everything was fine.
I also downloaded the latest version of DLDT (v 2020.4) and used the same cmake command as earlier. This version of DLDT checks for the minimum required Cython version which is 0.29 and this led me to the answer.
Another option to install and build openvino on Raspberry pi 4,
Download raspian installer 2019 version from https://download.01.org/opencv/2019/openvinotoolkit/R3/
Follow the step given in this link - https://docs.openvinotoolkit.org/latest/openvino_docs_install_guides_installing_openvino_raspbian.html
I am a beginner on jekyll. I am following the documentation advice to Build the site on the preview server.
Here is what a did :
- install the last version of ruby
$ruby -v -> ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin16]
$ gem --version -> 2.6.14
- Install Jekyll
$gem install jekyll bundler -> Version of jekyll : jekyll-3.6.2
When I try to build the site on the preview server (bundle exec jekyll serve) there is the following error :
jekyll 3.6.2 | Error: (/Users/admin/Documents/Perso/Site-Internet/Jekyll/inger/_config.yml): did not find expected key while parsing a block mapping at line 16 column 1
the line 16 is the first line uncommented that shoul be processed. It is this one
title: Inger Hair at Home at Aix en Provence (line 16)
I don't see what can be wrong. Thank you in advance for your answers
Yaml files are sensitive to spaces, in your _config.yml you have:
# Exclude from processing.
# The following items will not be processed, by default. Create a custom list
# to override the default setting.
exclude:
- Gemfile
- Gemfile.lock
- node_modules
- vendor/bundle/
- vendor/cache/
- vendor/gems/
- vendor/ruby/
- Inger-Analytics-feb0aa8b73d1.json
- .gitignore
When it should be:
# Exclude from processing.
# The following items will not be processed, by default. Create a custom list
# to override the default setting.
exclude:
- Gemfile
- Gemfile.lock
- node_modules
- vendor/bundle/
- vendor/cache/
- vendor/gems/
- vendor/ruby/
- Inger-Analytics-feb0aa8b73d1.json
- .gitignore
Note the space before exclude:. Then it should work.
I'm trying to build some lambda's in node.js and I am using TypeORM with MySql. I have installed all required node modules but when I deploy lambda (via serverless) and test it, I get errors as follows.
Using gulp to build and package .zip.
Log output from test lambda:
START RequestId: 671bed10-81b0-11e7-af34-251688cfdd Version: $LATEST
2017-08-15T11:53:50.594Z 671bed10-81b0-11e7-af34-251688cfdd
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection
(rejection id: 2): DriverPackageNotInstalledError: Mysql package has
not been found installed. Try to install it: npm install mysql --save
2017-08-15T11:53:50.596Z 671bed10-81b0-11e7-af34-251688cfdd Method:
"GET"
2017-08-15T11:53:50.596Z 671bed10-81b0-11e7-af34-251688cfdd Started
....
2017-08-15T11:53:50.596Z 671bed10-81b0-11e7-af34-251688cfdd
Finished ....
2017-08-15T11:53:50.596Z 671bed10-81b0-11e7-af34-251688cfdd
(node:1) PromiseRejectionHandledWarning: Promise rejection was handled
asynchronously (rejection id: 2)
2017-08-15T11:53:50.597Z 671bed10-81b0-11e7-af34-251688cfddb2
Console error: { DriverPackageNotInstalledError: Mysql package has not
been found installed. Try to install it: npm install mysql --save
at t.Error (native)
at new t (/var/task/index.js:1:48637)
at e.loadDependencies (/var/task/index.js:1:314938)
at new e (/var/task/index.js:1:311241)
at e.createDriver (/var/task/index.js:1:111709)
at e.create (/var/task/index.js:1:104246)
at e.<anonymous> (/var/task/index.js:1:110994)
at r (/var/task/index.js:1:103453)
at Object.next (/var/task/index.js:1:102788)
at /var/task/index.js:1:102697
name: 'DriverPackageNotInstalledError',
message: 'Mysql package has not been found installed. Try to install
it: npm install mysql --save' }
END RequestId: 671bed10-81b0-11e7-af34-251688cfdd
REPORT RequestId: 671bed10-81b0-11e7-af34-251688cfdd Duration: 8.71
ms Billed Duration: 100 ms Memory Size: 1024 MB Max Memory
Used: 39 MB
My research has led me to believe that it won't package correctly because its a native module. But i'm not sure. If so is there anyway to get native node modules to work with lambda's??
Any help would be much appreciated, thanks.
EDIT
Folder Structure:
deploy
-- dev
---- serverless.yml
---- PROJECT.zip
-- test
---- serverless.yml
---- PROJECT.zip
-- prod
---- serverless.yml
---- PROJECT.zip
node_modules
-- *
---- *
src
-- api
---- User
------ index.ts
-- data
---- User.ts
-- models
---- User.ts
gulpfile.js
index.ts
package.json
tsconfig.json
tslint.json
Gulp file calls a function from aws-lambda-typescript module that has numerous gulp tasks.
const gulp = require('gulp');
const awsLambdaTypescript = require('aws-lambda-typescript');
awsLambdaTypescript.registerBuildGulpTasks(gulp, __dirname);
Gulp packages .zip in a dist folder and then i copy to deploy>dev and then serverless deploy.
Thanks for your help!
I had a similar issue while testing the lambdas using the Serverless framework. I was using TypeORM and Postgres. So instead of mysql package I used the pg package, but got similar error: pg package has not been found installed.
After investigating for sometime I found that while building the code it was not including the pg package. The pg package was used internally and there was no reference of it in my code. So I thought this could be a reason why it is not being included in the build. To test this I added a reference to the pg package in my code by simply adding a console log.
import * as pg from 'pg';
console.log('This is just to add the reference : ', pg);
And it worked.
I think while packaging, the pg/mysql package is being excluded due to tree shaking or some dead code elimination mechanism. So just try to add a reference of the package in your code and see if it works or not.
import * as mysql from 'mysql';
console.log('This is just to add the reference : ', mysql);
I know it's late to answer but I hope this helps someone in future.
Most likely something is wrong with your packaging process. I'd check the following items:
Check your package.json if mysql is there.
Check the zip file inside your .serverless directory to see if it includes your node_modules.
Download the lambda package that you uploaded and again check if node_modules are there.