Getting rid of print

[gflorent]

Reading this thread, I came to think of the particular issue of 'print' statements in a wider context.
As a newby to FreeCAD (the good side is I have a new eye, the other side being having a lot to learn), but with a longer experience with Python and development in general, my opinion is that a 'Dos and Donts for FreeCAD Workbench developpers' kind of document (that would sound cooler than a Norms&Standards term that would likely be used in the corporate world) would help to somehow harmonize how things are done in the many workbenches that make FreeCAD such a rich and capable tool. I have browsed the code of about 10-15 workbenches and each one seems to have its own ideas about formatting, testing strategy, reporting, user workflow ....The only thing I saw in the wiki that came close to trying to harmonize development is a list of snippets.
I believe that if you are going to invest hundreds of hours in developping a workbench, 20 minutes of reading a recommended way to do things is reasonable.
I can volunteer to maintain such a document for about a year. But first, what are your opinions about such a document?

[DeepSOIC]

what are your opinions about such a document?

I would appreciate that!

I think, one of the most important things to cover is how to organize file structure and imports of a workbench.

[joha2]

what are your opinions about such a document?

I also really would like such a document. Maybe it would be better to open up a new thread for this.

Best wishes
Johannes

[GeneFC]

what are your opinions about such a document?

A document is fine, but you should be aware that many or most workbenches are several years old and have a lot of history. It seems somewhat unreasonable to expect the existing workbenches to be rewritten for what is mostly cosmetic purposes.

Gene

[looo]

I think, one of the most important things to cover is how to organize file structure and imports of a workbench.

covered here...
https://github.com/FreeCAD/Workbench-St ... to-freecad

But I know not everyone is a friend of this...

[DeepSOIC]

covered here...
https://github.com/FreeCAD/Workbench-St ... to-freecad

OK, but even I am having a hard time understanding it. Way too slangy technical. Maybe reserve all the new style / old style discussions to the addendum of a dedendum (i.e. certainly don't start with it).

Also, if one searches for "freecad how to make a workbench", you get this: Workbench creation. Giving a link to your template there might be a good move. Otherwise, I'm afraid, few will ever find the template.

* simple link the extension to a location where python can find it.

Did you mean "symlink"? And again, symlink isn't something everyone understands. Maybe just say "Place your module folder in a location where freecad can find it"?

[looo]

Did you mean "symlink"? And again, symlink isn't something everyone understands. Maybe just say "Place your module folder in a location where freecad can find it"?

Why changing python with freecad? In the end freecad uses python to import the modules, and with the new style modules there is nothing special about these modules. No differences to a pure python module. Only the files for the initialization (init_gui.py, init.py) are special.

In the end I guess it's best to suggest to use pip also for installing a module in development-mode.

[DeepSOIC]

In the end I guess it's best to suggest to use pip also for installing a module in development-mode.

Maybe. I'm just too oldschool, I'm still doing it with symlinks for a workbench I develop. I had no idea pip could install a workbench for development, and what it actually does.

Why changing python with freecad?

because it's freecad's python that has to be able to find it, not an abstract python installed elsewhere. On windows, it seems there is a difference. IDK about linux and others.

[joha2]

because it's freecad's python that has to be able to find it, not an abstract python installed elsewhere. On windows, it seems there is a difference. IDK about linux and others.

Maybe I can give some example usecase for @looos argument:

For our optical design python package (pyrate) it should be possible to perform calculations without freecad. Therefore, this is a usecase where it makes sense to also get the package via classical pip installation. In this case the most important question is (@looo and I discussed this already): How to provide the additional freecad functionality to provide a reasonable user interface without breaking the main core of the package?

Maybe there are more packages like ours which have a main core running at the console and just lightweight freecad integration. For those it would be nice to also run on an abstract python installation elsewhere.

Best wishes
Johannes

[looo]

Maybe. I'm just too oldschool, I'm still doing it with symlinks for a workbench I develop. I had no idea pip could install a workbench for development, and what it actually does.

because it's freecad's python that has to be able to find it, not an abstract python installed elsewhere. On windows, it seems there is a difference. IDK about linux and others.

I guess you are thinking about it this way because you are a windows user. Some people (mainly windows user) see FreeCAD as an own package which should use it's own python version. Others see FreeCAD as a module which should integrate with the python-world and should use libraries from the system. These two views have some conflicts. (portability vs modularity)

To solve this I guess it's best to make pip available from within FreeCAD. Not only to install/uninstall packages from pypi but also to install packages in development mode.

ps.: As this is getting a bit OT, maybe the discussion can be moved to:
https://forum.freecadweb.org/viewtopic.php?f=22&t=29584