Python.NET March 2020

pythonnet@python.org

7 participants
13 discussions

Working group notes for Feb 27, 2020
by Mark Visser 21 May '20

21 May '20

Attendees: Victor, Mark, Benedikt, Benoit, Amos, Felix Agenda Review action items from last meeting: Benoit to finish wiki page for threading Victor will talk to Benedikt regarding creating a lib/separate repo for codecs (this also applies to QuantConnect) Quantconnect PR - Victor to ensure Amos commits are mirrored in master Amos should take over PR #1016 Victor will try to review #958 instead See if Benedikt needs better time or we can make decisions while he’s off Unity is settled on 2.4.0, and might reduce presence Create NuGet organization and transfer package ownership for NuGet package <https://www.nuget.org/packages/pythonnet/> At least 1 more person to admin NuGet org Mailing list for maintainers only A plan to replace IntPtr with the new reference types Upstreaming Lost Tech (Victor’s) fork Python 2 support? DllImport -> GetDelegateForFunctionPointer Notes Wiki page for threading is up in tutorials section Victor & Amos discussing failing multithreading test case in PR #1022 Looks like Amos's commits in the Quantconnect PR are already in master PR #1016 closed in favour of using PR #958 instead Slow going on PR #958 review needs some description to explain the changes - a few sentences that describe the intended effects of the changes: what actions are necessary to implement soft shutdown? hard to get overall picture of what the code is expected to do Regarding the time slot this is the best we can get that balances China, North America and Germany time zones it's OK for Victor make decisions in the meeting - unless Benedikt is completely against the decision, it will be OK NuGet org Victor has access problem is that registered e-mail is the mailing list e-mail, security hole A plan to replace IntPtr with the new reference types we should avoid using IntPtr in our own pull requests should use proper pointer types ourselves, once we've got good practices established can be documented belongs with Benedikt's work on loader PR Upstreaming Lost Tech (Victor’s) fork Python 2 support not handled, should we drop support from master (and move 2.x to branch)? DllImport -> GetDelegateForFunctionPointer change require dropping 2.x in general dropping 2.x helps with a lot of things not a problem for Unity, also moving to 3.x No arguments against dropping support for 2.x in master were raised is master in a good state for a last release of 2.x? have one last push to get any changes not specific to 3.x into master before branch-off / tag codecs other minor changes stability of current release? random CI failures we added more tests recently - e.g. domain reload tests unstable one of the domain reload tests often fails on Python 2.7 Amos' changes for normal mode shutdown should solve these failures - should we land them first? no, let's only backport them if there is demand master is currently green As soon as we have all PRs we want in, we will tag 2.4.1 (if no breaking changes, 2.5 otherwise) and branch if necessary will use a github milestone to track PRs for 2.4.1 Still failing tests on 3.8, but likely a dependency on 3.7 - next release should have 3.8 support Lost Tech branch has support for Python version independence (except for 3.8) complete version independence requires dynamic tp slot handling will need runtime logic for handling different versions of Python to handle differing slot locations also need to remove PInvoke usage solving for these two issues will allow any Python version to be used at runtime instead of requiring pre-build for specific versions Lost Tech branch doesn't handle embedding C# in Python, but CLR loader PR should take care of this - already working, and should work with Lost Tech branch changes Dynamic CLR loading won't support 2.4 Action Items Victor will create codecs repo on github Amos to create issue or PR to make implicit operator for reference types to convert reference to IntPtr Amos will create wiki page to explain soft shutdown Benedikt will look into creating a private mailing list for maintainers only Everyone - tag PRs you want to land in 2.4.1, we'll try to get merged before next release Benedikt to check that modernization branch will work with 3.8 The meeting notes google doc is here <https://docs.google.com/document/d/1rJVU84B_dgx58-_EopjRtOJVFAI2WfHJYV0n7uE…>. Feel free to correct or add additional information. The next meeting will be held on Thursday, March 12th at 12pm EST, 9am PST, 6pm CET, 1am China. Mark Visser Tooling Dev Manager Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 3

Working group notes for March 26, 2020
by Mark Visser 27 Mar '20

27 Mar '20

Attendees: Victor, Benedikt, Amos, Mohamed, Mark Agenda Review action items from last meeting: [x] Mohamed will work on list and action codec PRs [x] Victor will ask Benedikt about older solution files/create an issue [x] Victor will look again at Mohamed’s issue with VS 2019 [ ] Continue PyHandle/References discussion on GitHub [x] Victor will start a discussion about serializing user objects - it might be highly misleading [ ] Amos will create a test for WrapperStorer demonstrating it release plan? Notes List & action codec PRs working through comments will put function codec into codec repo older solution files everything has not been converted to new project format old solution files still used by one of the appveyor builds Mono build uses xbuild? we should use .NET CLI for building what if users only have mono? building by yourself is painful older solutions should be removed Benedikt has removed it in a branch serializing user objects discussion will continue in PR private mailing list has been created contact Benedikt/Victor if you want to be on the mailing list use this for any future security issues / contacts joining .NET foundation got a new questionnaire, upcoming boarding meeting discussing new applications please review PR #1094 on finalize that Victor created what's going in the next release? finalizing Python 3.x support should go in memory dump can go in nested namespaces? Benedikt: deprecation warning about implicit loading is wrong and we should remove it codec groups? re: IronPython compatibility import system vs. import clr current system replaces __import__ and is overly invasive Action Items [ ] Viktor to create issue to track removing old solutions [ ] Continue PyHandle/References discussion on GitHub [ ] Amos will create a test for WrapperStorer demonstrating it [ ] Amos please review PR #1094 [ ] Benedikt will review codec groups PR The meeting notes google doc is here <https://docs.google.com/document/d/1rJVU84B_dgx58-_EopjRtOJVFAI2WfHJYV0n7uE…>. Feel free to correct or add additional information. The next meeting will be held on Thursday, April 10 at 12pm EST, 9am PST, 6pm CET, 1am China. Mark Visser Tooling Dev Manager Unity Technologies - www.unity3d.com <http://www.unity3d.com/>

1 0

Re: Building with vs2019
by Victor “LOST” Milovanov 12 Mar '20

12 Mar '20

1 0

Working group notes for March 12, 2020
by Victor “LOST” Milovanov 12 Mar '20

12 Mar '20

1 0

Building with vs2019
by Mohamed Koubaa 09 Mar '20

09 Mar '20

Hello, At my organization we use a release of VS2017 that does not include the 7.3 version of the C# compiler and cannot update because we are fixed to a specific C++ ABI. I am trying to use VS2019 to build and deploy pythonnet using some tips I found here<https://github.com/dotnet/performance/blob/master/src/benchmarks/gc/docs/py…> but hit this issue when building clrmodule.15: Error MSB4062 The "RGiesecke.DllExport.MSBuild.DllExportAppDomainIsolatedTask" task could not be loaded from the assembly C:\Users\mkoubaa\.nuget\packages\unmanagedexports\1.2.7\tools\RGiesecke.DllExport.MSBuild.dll. Could not load file or assembly 'Microsoft.Build.Utilities, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask. clrmodule.15 C:\Users\mkoubaa\.nuget\packages\unmanagedexports\1.2.7\tools\RGiesecke.DllExport.targets 58 Has anyone got this to work and if so what did you do? A better question might be how UnmanagedExports is making use of Microsoft.Build.Utilities. I know that there is a modernization project<https://github.com/pythonnet/pythonnet/projects/6> that may address this in the future. Thanks! Mohamed Koubaa Software Developer ANSYS, Inc

1 0

Re: DLL Processor compatibility
by Victor “LOST” Milovanov 05 Mar '20

05 Mar '20

1 0

Re: DLL Processor compatibility
by Victor “LOST” Milovanov 05 Mar '20

05 Mar '20

3 2

Re: DLL Processor compatibility
by Victor “LOST” Milovanov 04 Mar '20

04 Mar '20

2 2

[NuGet Gallery] Recent changes to your organization's email
by NuGet Gallery 04 Mar '20

04 Mar '20

The email address associated with your NuGet Gallery organization was recently changed from pythondotnet(a)python.org to pythonnet-dev(a)python.org. Thanks, The NuGet Gallery Team Privacy Statement (https://go.microsoft.com/fwlink/?LinkId=521839) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA

1 0

Re: Accessing a list that is a read-only property?
by Victor “LOST” Milovanov 04 Mar '20

04 Mar '20

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Python.NET March 2020