Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Python.NET recipe #159

Merged
merged 25 commits into from
Nov 30, 2022
Merged

add Python.NET recipe #159

merged 25 commits into from
Nov 30, 2022

Conversation

Livius90
Copy link
Contributor

Python.NET (pythonnet) is a package that gives Python programmers nearly seamless integration with .NET Framework, .NET Core and Mono runtime on Windows, Linux and macOS. Python.NET provides a powerful application scripting tool for .NET developers. Using this package you can script .NET applications or build entire applications in Python, using .NET services and components written in any language that targets the CLR (C#, VB.NET, F#, C++/CLI).
http://pythonnet.github.io/

Python.NET uses flit-core package for installing. Flit-core is supported since Yocto kirkstone release.

@Livius90
Copy link
Contributor Author

@ajlennon
Can you help and share some info about your proxy in your test build? In pythonnet and clr-loader recipe there is a "dotnet restore" which can not work well in your test build. I got this same issue in my Yocto project, i could solve it with the following proxy variable defines.

@ajlennon
Copy link
Member

Hi @Livius90 I'm not really following I'm afraid as there shouldn't be a proxy in place in the CI build as far as I know?

@ajlennon
Copy link
Member

Ah! I recall something about this now. Yocto now disallows internet access by default during compile steps unless it is specifically configured to support this. There are some notes in an issue here but I can't find them at the moment

@Livius90
Copy link
Contributor Author

Livius90 commented Nov 12, 2022

As i understand nuget package manager is integrated in dotnet, pythonnet and clr-loader .NET projects like to trigger a "dotnet restore" command to restore all of nuget packs from internet. Is it possible somehow let it to get an internet connection? In my local company machine i got the same issue but it was caused by my incorrect proxy settings, now it is different a little in your CI build test.

@Livius90
Copy link
Contributor Author

Livius90 commented Nov 17, 2022

@ajlennon
I tested your proxy setting with the following commit: 76a6a45
As i see, you use a docker for build-and-test action and in bitbake log http_proxy and https_proxy env variables are totally empty, it means dotnet restore can not use a correct proxy settings for downloading nugets.

Do you know what should be these proxy variables for your docker?

That same issue was in my company machine too, i could solve it nicely by a pre-defined DOTNET_HTTP_PROXY and DOTNET_HTTPS_PROXY variable in local.conf.

How to configure proxy for NuGet while using Docker?

@ajlennon
Copy link
Member

Hi - well we can change the envvars if you think it'll help? I still don't really understand why it would be needed but we could give it a go. I would think we could set these in the GitHub YAML. I'm out diving in Egypt until next week but maybe could could try a PR with that which the CI could build in the meantime ?

@Livius90
Copy link
Contributor Author

Livius90 commented Nov 18, 2022

I do not know what is your proxy and docker details. I can try to set http_proxy and https_proxy variables to an url value what you can give me first. But probably need any further proxy settings in your docker config too before.

@ajlennon
Copy link
Member

Well this is what I don't understand. I have no proxy setup and it all works fine... the container access the internet constantly to download source...

@Livius90
Copy link
Contributor Author

Livius90 commented Nov 19, 2022

In my company's Linux machine i got http_proxy=http://127.0.0.1:3128 in default Linux environment because we have an installed NTLM. Inside bitbake, dotnet restore was failed always for me also with the same errors but when i did dotnet restore manually in my terminal, it works, magically. I know that this local proxy IP just forwarding the proxy request to an http://my.copmany.com:3128 url, finally i tried to override http_proxy and https_proxy to this direct domain url and it was started to work well for dotnet restore command in bitbake task, too.

There are some many really similar problem in GitHub issues, there are some hints to change any other NUGET env variables to solve it. I will try these things soon.
NuGet/Home#6978

@ajlennon
Copy link
Member

There is no proxy... the container accesses the internet directly...

@Livius90
Copy link
Contributor Author

Livius90 commented Nov 27, 2022

There is no proxy... the container accesses the internet directly...

Just for try i put a webcontent downloading in bitbake task via curl and it seems, internet access is not healthy in your docker, curl can not reach api.nuget.org where the nuget package sources are available.

curl: (6) Could not resolve host: api.nuget.org

https://github.com/DynamicDevices/meta-mono/actions/runs/3555147656/jobs/5971666960#step:7:11572

Is DNS configured well in your docker?
microsoft/vscode-dev-containers#1471

Multiple ethernet LAN/WiFi card in your PC can cause it also.
docker/for-win#2760

@ajlennon
Copy link
Member

Is DNS configured well in your docker?

Well I am having a look but I can't see how it's possible that DNS is generally broken as the docker container is constantly downloading lots of source files from the Internet...

@ajlennon
Copy link
Member

OK so I have entered the docker container and I can see I can retrieve the json file OK...

image

@Livius90
Copy link
Contributor Author

Livius90 commented Nov 27, 2022

Hm, it means somewhy in the bitbake compiler task environment the network accessability is different somehow then in your normal docker terminal console has. Possibble it is a docker vs. Yocto bitbake vs. dotnet triple network issue, there are some issue tickets with the similar problem, there were some hints to use hard DNS address and other ideia was to set a metric/priority settings for multiple ethernet LAN connections, if it has, but unfortunately these issues was closed without final solution.

That problem is realy big issue because a Yocto recipe can use dotnet-native for any simple cross-compilation for .NET 6.0 apps but if their apps have any nuget depedency it can be easily failed in a docker container. For me in my phisical copmany's Ubuntu Linux machine i got only a proxy missconfiguration problem, i could solve it quickly via the http_proxy environment variables. Probably on any non-proxy and non-docker building Linux machines can use well dotnet-native in a recipes but this situation is not so nice, if it randomly can not work or can work in a docker containers.

@ajlennon
Copy link
Member

SyntaxError: unexpected character after line continuation character

@Livius90
Copy link
Contributor Author

I could not leave DOTNET_HTTP_PROXY definition in my last test. My company's proxy work well only if i pre-define it in my local.conf. Usage of do_compile[network] = "1" does not matter for it.

@Livius90
Copy link
Contributor Author

Livius90 commented Nov 29, 2022

@ajlennon
How can we add a custom unit-test recipe for pythonnet on qemu machine target? We can execute the .NET core tests from pythonnet source easily like pythonnet action/workflow do it here.

Need to just execute the following command in tests folder of pythonnet repo.

python3 -m pytest --runtime coreclr

@ajlennon ajlennon merged commit 35d7818 into DynamicDevices:master Nov 30, 2022
@ajlennon
Copy link
Member

Merged in. That's great. We got there in the end and it also validates the whole CI testing setup for me.

You can probably enable unit testing on these recipes as Yocto supports this.

The other way is to add some test classes as I've done for some specific simple tests which will be run during the CI build in QEMU

e.g.

https://github.com/DynamicDevices/meta-mono/tree/master/lib/oeqa/runtime/cases

zboszor pushed a commit to zboszor/meta-mono that referenced this pull request May 10, 2023
* dotnet: update to v6.0.11

* python: Add Python.NET v3.0.1

* python3-clr-loader: fix typo

* pythonnet: fix proxy config

* pythonnet: separated folder for nuget downloads and cache

* python3-clr-loader: test proxy

* dotnet restore try to fix DynamicDevices#1

* dotnet restore next try

* dotnet restore try some http env settings

* dotnet restore fix libcurl-native syntax

* dotnet restore curl fix

* dotnet restore test http download

* dotnet restore http next try

* dotnet restore test DNS

* dotnet restore, dns fix not works, revert some parts

* dotnet restore fix, version appending fix in __init__.py

* fix endline, restore original yml

* fix again endline

* fix again endline and trigger a new fetch

* append endline in do_patch, restore latest package versions

* do_configure:prepend() must be used for version append

* append __version__ only if it is does not exist

* fix typo

* if proxy used, it must be defined in task environment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants