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?
Related
One of my Open Source projects uses Packages to build the macOS installer. After GUI-based setup of the pckgproject file, the installer build can be easially invoked from the command line through the packagesbuild command.
I'm now setting up a GitHub Actions based build workflow, running on the GitHub-hosted runners, which should ideally create a ready-to-use installer, so I need to invoke packagesbuild during that process. Unfortunately packagesbuild is not available on the macos-10.15 runner used. I don't see any option to install it during the workflow run, as it's not available through e.g. homebrew but maybe I'm overlooking something. Is there any option I'm overlooking beneath rebuilding my installer and switching to pkgbuild?
I have tried deploying app through heroku through cli and through linking git repo, through the git repo I am now getting
! Warning: Multiple default buildpacks reported the ability to handle this app. The first buildpack in the list below will be used.
Detected build packs: Python, Node.js
However, when I try to uninstall python build pack as explained here (https://devcenter.heroku.com/articles/buildpacks) it says it can't be detected. When I try to install Node build pack it says it cannot be detected. But when I press deploy branch it runs the python pack since it is apparently the first build pack in the list.
I have tried making a requirement.txt file as noted in other answers but that took me from error in the post title to the error listed above with multiple packs
Normally a bower.json file specifies some dependencies, but these are typically expressed so that they allow a range of versions of a bower package to be used (e.g. >=1.0, which means anything higher than version 1.0).
I have an automated process which needs to find what version of a bower package is actually installed on this system right now.
How can I find this out programmatically (just the version itself), ideally using standard Unix command line tools / the bower command?
bower info <thepackagename> does not show this - it shows information about what is currently available from the bower repository (for example, even if I do bower info apackageIdonthaveinstalled it will still show a valid JSON structure containing a version number).
cat bower_components/thepackagename/bower.json | node_modules/json/lib/json.js version works for some packages (assuming the npm package json is installed), but not all (e.g. jquery 2.2.0's bower package does not contain a bower.json).
Here's a grep command to do that:
grep "version\"\:" bower_components/thepackagename/.bower.json
Also, a command to see versions of all bower components for the project - this list can be a handy CI artefact:
grep "version\"\:" bower_components/*/.bower.json
Have you ever tried "bower list --json=0 --offline".
It would list all bower packages info.
The best approach I've now found, which seems to work for every package I've come across so far, is:
cat bower_components/thepackagename/.bower.json | node_modules/json/lib/json.js version
(note the extra . in .bower.json).
It would appear that bower stores some metadata about the installed package in .bower.json, and that includes the installed version.
The best I've come up with so far is:
bower list | grep jquery | perl -pe 's/.*jquery#(.*?) .*$/$1/'
(if, for example, the package I was interested in was jquery).
That's pretty ugly for a variety of reasons:
I have to repeat the package name (although this could probably be improved
with a better Perl script which filters lines too, I'm just being lazy).
bower list gets information about all installed packages, not just the one I'm interested in - the rest of the information is discarded.
bower list seems to require internet connectivity to check the registry, otherwise it fails.
Would be interested to see if this could be improved upon, particularly the last point.
I'm following the instructions from here to build MonoDevelop on Mac OS X: Building MonoDevelop on OS X
I can build MonoDevelop just fine. I'd like to also build the MonoMac add in and use it.
The document says:
"To include addins from extras, manually copy their build directories
into the MonoDevelop.app directory, e.g.
cp -r ../../../extras/MonoDevelop.AspNet.Mvc/build/*
MonoDevelop.app/Contents/MacOS/lib/monodevelop/AddIns/MonoDevelop.AspNet.Mvc/"
However, I have no build directory under /extras/MonoDevelop.MonoMac.
I tried to follow this step to build extras:
"To include additional addins from extras in the build, instead of
using the Mac profile, use configure --select to select addins. This
will write the default profile. Next, replace the line in
profiles/default that begins with "main" with the one from
profiles/mac, then run configure again using the default profile."
But it does not give me the option to build the MonoMac extra.
Next, I try to compile the monodevelop.mdw. Again, I can build the main solution (MonoDevelop), but the extras fails with over 1000 errors.
Finally, I tried to take my existing monomac and macdev plugins and copy them into my master monodevelop.app bundle. But this breaks add solution/project dialog whenever I try to select a MonoMac project - it fails to load the Monodevelop.ide DLL.
Any advice on where I am going wrong would be appreciated.
I was not able to make this work following the directions on the MonoDevelop site. Even manually adding the extras/MonoDevelop.MonoMac extra to the profile did not work.
In the end, I build MonoDevelop from source, using the mac profile.
Then I got the latest MonoMac pieces, and build them from source. I used
make update
to install into my installed copy of MonoDevelop.
Then, I manually copied the following packages from my installed MonoDevelop to my newly compiled version from master:
MacPlatform.dll
MonoDevelop.iPhone
MonoDevelop.MacDev
MonoDevelop.MonoMac
Xamarin.Ide
Any everything now works :)
I compiled MySQL++ with no issues. When I launched some of the executables (resetdb.exe and simple1.exe) they suggest to run to test if the installation has been successful, the first error I got was that libmysql.dll was missing.
Adding its path to the PATH environment variable did not fix the problem, even after launching a new command prompt; I had to copy the DLL in the directory where MySQL++ executables are.
Now the DLL is found, but I get this error:
simple1.exe - Application error
The application was unable to start correctly (0xc000007b).
Click OK to close the application.
even launching from the command line, I get no more information than these.
Thank you for any help!
MySQL 5.5 -
MySQL++ 3.0.9 -
Windows 7 64 bits -
MINGW32 -
GCC 4.4.0
0xC000007B is a Windows error that means the executable is corrupted. It could refer either to simple1.exe or to one of the DLLs it's linking against.
Some reasons this could happen:
You're mixing toolchains in an incompatible way. In your case, you may have built simple1.exe using pieces built by MinGW GCC and pieces built by Visual C++. MinGW should be compatible with any pure C DLL built by Visual C++, including the MySQL C API DLL. However, you may have other pieces interfering. MinGW isn't compatible with VC++ at the C++ level, but then, it shouldn't have linked at all if this were your problem.
You didn't follow the MySQL C API import library build steps in README-MinGW.txt. You either missed a step, or skipped it entirely and are trying to use the import library that shipped with MySQL.
In your previous gyrations, you ended up with a corrupt object file, which got linked in. Try saying make clean all at the top level of MySQL++ to force a complete rebuild.
You're mixing versions of MySQL or MySQL++. If you have more than one version of each on the system, make sure you're consistent in their use. That is, build the C API import library from the same DLL you run the programs against, use exrun.bat to run the examples to ensure you're using the just-built version of the MySQL++ DLL instead of another you have in your PATH, etc.
Additionally, I note that you're using an older version of MySQL++. If you were on Linux, I could understand that as some distributions still ship with 3.0.9. But since you have to build MySQL++ from source with MinGW, I don't see why you're not using 3.1.0. Did you get a binary build from somewhere?
As for your PATH problem, did you restart the MinGW shell after doing this? PATH updates don't affect running programs; they keep the value they saw when they started.