I'm running a python binary target with bazel run xxx and in the target I'm doing print(sys.version). This outputs Python version 3.6.8 (default, Jan 14 2019, 11:02:34)
When I type the python command directly, I get Python 3.7.3 (default, Apr 3 2019, 19:16:38)
Why/how did bazel choose a different python version?
Bazel will choose different python versions based on the configuration of the build. If nothing is overriden, bazel will use its default python version. This can be overridden by passing --python_version=<some_version> when running a bazel command.
https://docs.bazel.build/versions/master/be/python.html#py_binary.python_version
https://github.com/bazelbuild/rules_python/blob/120590e2f2b66e5590bf4dc8ebef9c5338984775/python/BUILD#L43
Related
I have a library that targets .NET Standard 2.0. To verify compatibility, I would like to run my unit tests with the current and long term support (LTS) versions of .NET Core. When this question was written, those were:
Target Framework
Target framework moniker (TFM)
.NET 5.0 (current)
net5.0
.NET Core 3.1 (LTS)
netcoreapp3.1
.NET Core 2.1 (LTS)
netcoreapp2.1
It's easy enough to set up the csproj files to target multiple frameworks:
<PropertyGroup>
<TargetFrameworks>netcoreapp2.1;netcoreapp3.1;net5.0</TargetFrameworks>
</PropertyGroup>
That works well for local builds when all of these SDKs are installed. However, I'd prefer to have my CI builds take place on a single, lightweight Docker container. I'm not worried about verifying .NET Framework support, so I don't need Windows. The .NET SDK images on Docker Hub work well for any single framework (i.e., mcr.microsoft.com/dotnet/sdk:5.0), but I would like to find a Docker image that includes all three of these SDKs without the baggage of a "kitchen sink" image like the GitHub-hosted runners, which include many unrelated frameworks and tools.
I could write my own Dockerfile, starting from a base image and scripting the installation of the extra SDKs, but surely I can't be the only person who could use something like this. Does a suitable Docker image already exist somewhere? Should I be taking a different approach to this problem, like scripting the SDK installation with setup-dotnet or an equivalent?
While the latest dotnet SDK can target any previous SDK versions,dotnet test requires the particular dotnet runtime. There are many ways to install dotnet sdk/runtimes into a base docker image, but the easiest is to just copy the SDK and/or runtimes from existing base images. Here's an example for dotnet 6, should you need the dotnet 5.0 runtime for unit tests:
FROM mcr.microsoft.com/dotnet/sdk:6.0 as build
#uncomment if you need the 5.0 SDK also (unlikely):
#COPY --from=mcr.microsoft.com/dotnet/sdk:5.0 /usr/share/dotnet/sdk /usr/share/dotnet/sdk
# "install" the dotnet 5 runtime
COPY --from=mcr.microsoft.com/dotnet/sdk:5.0 /usr/share/dotnet/shared /usr/share/dotnet/shared
If you run the above image and get into the shell and do dotnet --info it's as expected:
$ docker run -it --rm 0de6f2cdf814
root#b4bb146dcf7e:/src# dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.200
Commit: 4c30de7899
Runtime Environment:
OS Name: debian
OS Version: 11
OS Platform: Linux
RID: debian.11-x64
Base Path: /usr/share/dotnet/sdk/6.0.200/
Host (useful for support):
Version: 6.0.2
Commit: 839cdfb0ec
.NET SDKs installed:
6.0.200 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 5.0.10 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.2 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 5.0.10 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.2 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
root#b4bb146dcf7e:/src#
Just use the Docker image for the latest .NET version (currently mcr.microsoft.com/dotnet/sdk:5.0). It's capable of building projects that target different versions. It's the same as how you can do this locally on your dev machine. You can just install 5.0 SDK on your machine and build projects that target 2.1, 3.1, or 5.0.
If you're wanting to run unit tests in the same container, you will need to install the extra runtimes that you require for each of the versions other than 5.0. This will vary based on what OS you're targeting but you can find details on the installation at https://learn.microsoft.com/en-us/dotnet/core/install/. For example, on Debian, you can install ASP.NET 3.1 runtime with the following:
wget https://packages.microsoft.com/config/debian/10/packages-microsoft-prod.deb -O packages-microsoft-prod.deb && \
dpkg -i packages-microsoft-prod.deb && \
apt-get update && \
apt-get install -y apt-transport-https && \
apt-get update && \
apt-get install -y aspnetcore-runtime-3.1
I've tried to avoid building custom images and scripting extra runtimes, so my variant was to run build/test on multiple containers (sdk:2.1, sdk:3.1) separately.
Funny enough, having multitarget:
<PropertyGroup>
<TargetFrameworks>netcoreapp2.1;netcoreapp3.1</TargetFrameworks>
</PropertyGroup>
does not allow building on sdk:2.1 container, even if you specify that you only want to build for 2.1, with parameter -f netcoreapp2.1.
I ended up with conditioned csproj file, which specifies TargetFrameworks based on outside parameter. For example, my csproj configuration is:
<TargetFrameworks Condition=" '$(TestTargetFramework)' == '' ">netstandard2.0;netstandard2.1</TargetFrameworks>
<TargetFrameworks Condition=" '$(TestTargetFramework)' == 'netcoreapp2.1' ">netstandard2.0</TargetFrameworks>
<TargetFrameworks Condition=" '$(TestTargetFramework)' == 'netcoreapp3.1' ">netstandard2.1</TargetFrameworks>
And I can build/test it on sdk:2.1:
dotnet test ./test/Tests --configuration Release /p:TestTargetFramework=netcoreapp2.1
Or sdk:3.1:
dotnet test ./test/Tests --configuration Release /p:TestTargetFramework=netcoreapp3.1
I need to compile a project against LLVM/Clang 3.9.1 built with some particular flags (RTTI and CXX1Y), so in my .travis.yml I firstly download LLVM/Clang 3.9 source, then I build it as I need and finally I install it in /usr/bin.
When (after this phase) I try to run llvm-config --version and clang --version I discover that the version 5.0.0 is considered.
Is there a way to run a build on travis-ci without LLVM/Clang to be installed or a way to set the version 3.9.1 as the default llvm-config and clang executables?
Travis CI can be built without any preinstalled C/C++ compilers (e.g. set language: ruby in your .travis.yml file) but the better/safer way might be to specify your compiler explicitly in your build system. Like Stanislav mentioned in a comment, you could use CMAKE_CXX_COMPILER if you use CMake.
I'm using the Dart SDK in the latest install of Flutter:
Dart VM version: 2.0.0-dev.43.0.flutter-52afcba357 (Fri Mar 30 20:33:12 2018 +0000) on "windows_x64"
I can run individual tests with Dart 2.0 (now in preview) by using the --preview-dart-2 command-line argument, e.g:
$ dart --preview-dart-2 test\my_test.dart
But is it possible to run all tests with Dart 2.0, e.g:
$ pub run test
This only runs the test suite as Dart 1.x which doesn't seem to accept the --preview-dart-2 flag.
pub run doesn't support --preview-dart-2 yet and I'm sure pub test depends on pub run.
There is an open issue Implement --preview-dart-2 option for pub run #1807
How to exactly install dart editor in debian? Tried to build dart from the source on this site Building Dart on Debian up to the gclient runhooks and ran
$ cd dart
$ ./tools/build.py -m release -a x64
which they say will build ALL (including the dart editor w/c I prefer). But unluckily, the build fails after waiting a thousand years. Any ideas on how to properly install ALL the dart components on debian?
I tried a while ago and failed building Dartium on Debian.
It might make sense to build the Dart runtime you use for the production server yourself but IMHO building DartEditor and Dartium is not worth the effort on Debian.
To install the development environment I just download the Linux package and unpack it.
Situation:
In my Mac Os 10.8.5 I have available python2.7 and python2.7-32 with latest cx_freeze(-4.3.2).
I need cx_freeze to pick the python2.7-32 version so my executable app can use a 32-bit version of OpenCV.
So far, all attempts to use cx_freeze script suggest that it bundles python2.7(which is 64bit) and the app fails to execute with: "cv2.so: mach-o, but wrong architecture"
(This is the same error you would get if you try to import OpenCV built in 32 bits, with a python interpreter of 64)
Is there a way to "force" cxfreeze to bundle a specific python version installed (in this case python2.7-32) in the executable it produces?
Edit:
I've also tried to build cx-freeze from source in 32-bit using:
python2.7-32 setup.py build;
python2.7-32 setup.py install
No matter what, the app generated is still a 64bit version:
$ python2.7-32 setup.py bdist_dmg
$ file capturebasic
capturebasic: Mach-O 64-bit executable x86_64
$ arch -i386 ./capturebasic
arch: posix_spawnp: ./capturebasic: Bad CPU type in executable
Edit2:
It seems that Mac's cx_freeze you download from sourceforge is only 64-bit:
http://sourceforge.net/projects/cx-freeze/files/4.3.2/
If you want to create 32-bit apps, you need the 32-bit version of cx_freeze.
I'm confirming if there's any way to install the 32bit version in Mac in cx_freeze's mailing list.
I believe you do not have to touch your setup script, but just change the command used to build it. For instance instead of using python setup.py build, you would use the command python2.7-32 setup.py build. You may have to specify the path to the python2.7-32 exe. so something like path\to\python2.7-32.exe setup.py build. Note: I use windows so the example commands I used might be a little different on mac, like instead of .exe it's .app.
Hope this helped.