[Dune-devel] Python/Build system meeting: Input wanted
Simon Praetorius
simon.praetorius at tu-dresden.de
Thu May 27 11:26:16 CEST 2021
Hi Andreas,
I'm also in favor of a). The python bindings are clearly a great thing.
In order to thoroughly test it by a large community it needs to be
enabled by default. Although it has improved a lot since our last
meeting, I expect some corner cases to break. Fixing these will probably
take time. Releasing now would allow to have an up-to-date stable
release before we introduce these possibly breaking changes.
I'm also waiting for a stable release before I start including other
changes (cmake related). These are always a bit related to the python
bindings because you also need cmake for the setup and you have written
several cmake extensions. This needs to be aligned to the other cmake
changes. I think merging both things in the same release cycle (step by
step) and fixing incompatibilities by these two independent developments
would also need time and is better done after a stable 2.8 release.
So, in my opinion, we need to start now listing what needs to be done
for a release that is independent of the python bindings topic so that
we can start the release procedure soon. I think, Christoph has already
listed a few topics that needed to be fixed before 2.8, but some/most of
these points are already finished.
Best wishes,
Simon
Am 26.05.21 um 10:46 schrieb Dedner, Andreas:
> Hi,
> I would like to discuss how to proceed with the next release and the
> new Python bindings.
> Perhaps we need another developer meeting?
>
> I see a few options:
> (a) We release 2.8 with the current master (I would like to do this
> really quickly if that is the decision taken).
> After the release, the new python approach is merged.
> (b) We merge these branches now. Since this is a more significant
> change we would then wait for a few month
> until releasing 2.8, i.e., end of the year.
> (c) We decide not to merge this at all - or someone suggest some major
> modifications.
>
> In all three cases there is a further question: should the Python
> bindings be turned on by default?
>
> I've already got the first email from Gitlab that in one of the
> modules the branch can't be merged anymore - with 10 modules with a
> corresponding MR this could become painful quite soon, so I would
> appreciate not to have to wait for too long for a decision (or at
> least to know which parts are contentious).
>
> I'm happy to meet up with anyone interested during the next weeks for
> example - let me know if that would be helpful. Otherwise, discussions
> on any of the details of the changes should be done in
> https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960
> <https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960>
> That MR also contains an explanation of what is done - if something is
> unclear let me know.
>
> Greetings
> Andreas
> ------------------------------------------------------------------------
> *From:* Dedner, Andreas <A.S.Dedner at warwick.ac.uk>
> *Sent:* 05 May 2021 12:37
> *To:* dune-devel at lists.dune-project.org
> <dune-devel at lists.dune-project.org>
> *Subject:* Re: [Dune-devel] Python/Build system meeting: Input wanted
> Dear developers.
>
> This is a follow up from an email from Dominic (on 05/02).
> Following the discussion, we had on the Python bindings and the build
> internal virtual environment,
> Dominic started work on making the changes along the lines of what we
> discussed.
> Over the last week I've made some changes to get packaging and some
> other thngs up and running again based on these changes.
> The main merge request
> https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960
> <https://gitlab.dune-project.org/core/dune-common/-/merge_requests/960>
> contains hopefully useful information on the changes and some of the
> consequences.
> I would suggest having a discussion on the changes there. There other
> core modules (and some others) have companion MRs (still marked WIP).
> Best
> Andreas
>
> PS: At the time we asked everyone interested to summarize their use
> cases for combining Dune and Python.
> I just went through that list again and think everything is addressed:
>
> Adrian: can use pip install (and even combine with own source module)
> Babara: will now get an internal dune-env installed which she might
> not want
> Can disable by disabling the cmake lookup of Python but that is
> perhaps not obvious to her - perhaps give her an easy flag to
> set?
> Clara: should be mostly fine - differences are documented.
> But I guess there are different viewpoints on this
> Dominic: should be happy since internal venv is now on by default
> Andreas: works fine for me
> Linus: Can't say for sure but hope he's happy?
> Robert: A bit like Babara, i.e., might get an internal venv he
> doesn't use
> Oliver: Embedded is still a bit of an issue which is mostly a venv
> problem
> 1. An external venv is used: then everything should be fine
> 2. the internal venv is used: make tests will be fine but
> calling
> a C++ code directly will fail since the venv interpreter
> is not
> used and the dune packages are not found. Needs to run
> build-dir/run-in-env ./test
> This is an issue with venv/embedded that has been discussed
> on the venv
> mailing lists but never fixed
> Christian: These issues are a bit separate from these changes and need to
> be discussed separately, I think. Some of the things
> mentioned should
> work already I believe.
> At least I hope that current changes don't make things worse.
> ------------------------------------------------------------------------
> *From:* Dune-devel <dune-devel-bounces at lists.dune-project.org> on
> behalf of Dominic Kempf <dominic.r.kempf at gmail.com>
> *Sent:* 05 February 2021 16:15
> *To:* dune-devel at lists.dune-project.org
> <dune-devel at lists.dune-project.org>
> *Subject:* [Dune-devel] Python/Build system meeting: Input wanted
> Dear developers,
>
> we had a small meeting today that emerged from recent discussions on
> Gitlab issues + MRs to get an overview of the Python landscape in
> Dune. Participants were Andreas, Robert, Simon, Carsten, Samuel and
> myself. I think we made some progress, but we want to build on
> everybody's feedback to continue.
>
> We would like to collect a list of use cases formulated as fictional
> or non-fictional user profiles. Just add yours to the list:
> https://cryptpad.fr/pad/#/2/pad/edit/Cdg8eTGASWgdQetoM06emmp7/
> <https://cryptpad.fr/pad/#/2/pad/edit/Cdg8eTGASWgdQetoM06emmp7/>
> This list will serve as the basis of discussion to converge to a
> technical solution that accommodates the needs of as many users as
> possible and allows a consensus to enable the Python bindings feature
> by default in the future.
>
> Best,
> Dominic
>
>
>
> _______________________________________________
> Dune-devel mailing list
> Dune-devel at lists.dune-project.org
> https://lists.dune-project.org/mailman/listinfo/dune-devel
--
Dr. Simon Praetorius
Technische Universität Dresden
Institute of Scientific Computing
phone: +49 351 463-34432
mail: simon.praetorius at tu-dresden.de
web: https://tu-dresden.de/mn/math/wir/das-institut/beschaeftigte/simon-praetorius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20210527/9c99ece5/attachment.htm>
More information about the Dune-devel
mailing list