FOSDEM 2020 anyone?

[sliptonic]

Another subject that came up regularly was the need for a better way to manage python dependencies.

[apeltauer]

FOSDEM is over!! It was a great event, first time we had so many FreeCADers together!
Indeed the talk is now online at:
https://video.fosdem.org/2020/H.2213/freecad.mp4
https://video.fosdem.org/2020/H.2213/freecad.webm

Great video!!! Thanks for sharing....

Thanks both of you for your time and your passion for FC....

[wmayer]

Just to inform that we have not only been drinking beers (which might not be obvious looking at the pictures) but also did actual coding, the new SendToPythonConsole command has been coded during FOSDEM, which does the same as the already available functionality in the Selection view, but is now available throughout FreeCAD in the context menu (or via keyb shortcut)

thats a very good one, very useful !

Really?

The implementation raises several problems:

• It breaks the design because it makes again assumptions about implementation details of an extension module because it explicitly checks for a property called Shape
  I cannot repeat often enough that it's a no-go for the core system to make any assumptions about extension modules since it creates some kind of cyclic dependencies. To avoid such issues the core system offers abstract interfaces which the extension module must implement and when the core calls an appropriate function it executes the code of the extension module but it's of no interest what it does.
• The command only focuses on objects a Shape property and that supports sub-elements. All other object types that support sub-elements are completely ignored.
• The command just executes some Python code but from the console you have absolutely no clue what it really does. And the variable names it creates are not very intuitive IMO: obj and optionally shp and elt.
• It causes some side-effects. Imagine you have selected a face of a cube. When executing the command it creates the variables obj, shp and elt.
  Now you select another object in the tree view and run the command again. Now it overwrites only the obj variable but shp and elt still exist and it's not clear any more what they refer to.
• Also the workflow looks weird to me. You execute a command from the menu and then switch to the Python console and continue there. Why not then adding a function to the Python interface of the Selection module instead that returns a tuple of the form (object, geometric property, sub-element) where the last two are optional?

[triplus]

Really?

Therefore they did drink some beer?

Anyway, as far as the governance goes. I feel that in the past years, we were able to establish some structure and certainty. Things like doing an annual release in my opinion shows that. Somehow we all agreed that the holidays season is a rather important thing, hence a release around April makes sense. I doubt some governing body could just set a date, without having basically the same discussions, as we did in the past.

Moving Tracker to GitHub. I personally am not against or for such move. Whatever makes the main developers more happy. This shouldn't get decided based on some hipster motives, like lets move because tags system work better and we can tag better over there. As Microsoft owns GitHub, the overall appeal of GitHub did diminish a bit to some, currently it's likely still a reasonable option.

As for documentation purposes. Note that personally i still feel the MediaWiki is the dominant platform for creating such content. Said that i would first outline some possible solutions, and after ask the main document creators, if they can test such solutions and agree on some. As currently we are only talking about lets move and on how somebody will move something to somewhere. Nobody has ever said move to what, doing that for a while only introduces uncertainty.

Internal vs. external documentation. Don't know what the technical details are, do know that Qt Assistant can be a bit tricky sometimes. External documentation would likely lose the ability to use What's This command, some other technical solution might be used for that. Internal documentation is currently way too big and should reduce in size if possible.

As for the money, foundation, events. If an USA based foundation would be established, then indeed highly likely, due to the software patents laws, it makes sense to have some legal oriented entity on your side. If it wouldn't be USA based, for example it would be Brazil/German/Swiss/... based, best to talk to some local law representative, on what the legal options are. Having a foundation could lead to more company involvement, as there is an address, phone number, somebody you can send a mail, transaction account ... Bottom line in the end and based on an informed decision, somebody will need to sign something in some country, or the FreeCAD foundation just won't happen.

As for adding and removing FreeCAD modules. This one is tricky, as we can end up removing functionality, that doesn't cause any real issues and people still use. I would vote that once one FreeCAD module gets externalized, another one should get upstreamed. In the past couple of years we have just been talking about removing functionality, that is not the right signal in my opinion, and in addition we never really talked about adding modules. Out with the old, in with the new would be a nice compromise. Things like feature parity meet, superseding with the NEXT ... and at the same time having a candidate, bringing some new and matured functionality to upstream. Hard to argue with such strategy.

As for Python package distribution options, best to as @looo for some opinions. He has pretty much explored everything there is out there and likely has an idea, on what can and what can't work and to what extent.

P.S. Anyway, as this is/was FOSDEM 2020 thread i don't plan to further discuss in any heated debates, sharing my thoughts cross different threads would feel a bit less optimal.

[yorik]

The implementation raises several problems:

Hmm you raise very good points, as always...

I think there have been changes to the same tool found in the selection view (that isn't a proper FreeCAD command), it seems to handle any kind of subelement more gracefully. However it doesn't work anymore, that's why I went another path.. I should have a better look at it

The whole idea is to be a handy "bridge" for people who often use python while using the GUI, so names like obj, shp, elt are mostly meant to be easy to type and not really for use in more complex scripts. But you are right there too, after all these might get recorded in macros... In any case shp and elt should indeed be wiped out on re-run.

[wmayer]

I think there have been changes to the same tool found in the selection view (that isn't a proper FreeCAD command), it seems to handle any kind of subelement more gracefully. However it doesn't work anymore, that's why I went another path.. I should have a better look at it

OK, then this should be fixed, too.

To improve the new command:
A GeoFeature has the virtual method getPropertyOfGeometry() that returns the property with the actual geometry. From the returned pointer (if not null) you can determine its property name and use that in the Python code. So, if a Part feature is selected Shape should be returned.

The generated code is only visible when macro recording is enabled but if not you don't see the code. Since this is a somewhat special command the question is what to do if macro recording is off. To increase transparency it should be forced to write the code to the Python console ignoring user settings.

[looo]

Really?

Moving Tracker to GitHub. I personally am not against or for such move. Whatever makes the main developers more happy. This shouldn't get decided based on some hipster motives, like lets move because tags system work better and we can tag better over there. As Microsoft owns GitHub, the overall appeal of GitHub did diminish a bit to some, currently it's likely still a reasonable option.

Yes, please if somehow possible move the tracker to github. For me this would simplify my workflow a lot. There are already tools to move issues from github to another organization, so best to not care to much about the dependency on microsoft.

As for adding and removing FreeCAD modules. This one is tricky, as we can end up removing functionality, that doesn't cause any real issues and people still use. I would vote that once one FreeCAD module gets externalized, another one should get upstreamed. In the past couple of years we have just been talking about removing functionality, that is not the right signal in my opinion, and in addition we never really talked about adding modules. Out with the old, in with the new would be a nice compromise. Things like feature parity meet, superseding with the NEXT ... and at the same time having a candidate, bringing some new and matured functionality to upstream. Hard to argue with such strategy.

In the end there will be no other way than depending on package-managers. Therefore it should be possible to switch to a freecad-core + addons structure(also meta-packages which install everything needed for mechanical-eng, architecture and so on is possible). But for now, I agree we should keep the source as it is and modularize internally (porting internal python-only workbenches / modules to namespace-packages and allow installation to site-package-directory). This way we can also split the freecad-package during the package-creation...

Regarding internalizing external modules:
I think this is a good idea. One example is your pie-menu which I would like to see more tightly integrated.

As for Python package distribution options, best to as @looo for some opinions. He has pretty much explored everything there is out there and likely has an idea, on what can and what can't work and to what extent.

I have to admit that conda works the best and I will go on with this effort to also manage addons via conda. The design is a good mix between high-level packaging like pypi and system-package-manager like apt (but a lot easier to handle for maintainers and cross-palttform). For sure it's possible they (conda-forge) stop the support for qt, but as qt is moving to cmake it's possible building qt gets easier with version 6. So it would be nice to see more people working on conda-forge.
In the long run I hope either conda-forge is becoming fully independent from anaconda or that conda and pypi merge (there are currently already efforts to bring conda-packages to pypi. So theoretically it's possible to distribute freecad via pypi allthough there are for sure issues like PySide2 which has qt included on pypi.