FEAT: DXF import updates

[isaacwaldron]

Description

1. Use ezdxf instead of the existing custom solution to detect the plot layer names from DXFs for import, to support R12 version DXF files.
2. Relax restriction of DXF import in non-graphical mode as it seems to work in 2024 R2 at least.
3. Enable using the modeler's default tolerance for DXF self-stitching by supplying a negative value for self_stitch_tolerance.

Issue linked

Fixes #5520
Closes #5521
Closes #5522

Checklist

• I have tested my changes locally.
• I have added necessary documentation or updated existing documentation.
• I have followed the coding style guidelines of this project.
• I have added appropriate tests (unit, integration, system).
• I have reviewed my changes before submitting this pull request.
• I have linked the issue or issues that are solved by the PR if any.
• I have agreed with the Contributor License Agreement (CLA).

[ansys-reviewer-bot]

Thanks for opening a Pull Request. If you want to perform a review write a comment saying:

@ansys-reviewer-bot review

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.92%. Comparing base (273097b) to head (023ea4b).
Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5523      +/-   ##
==========================================
+ Coverage   84.90%   84.92%   +0.02%     
==========================================
  Files         144      144              
  Lines       60628    60628              
==========================================
+ Hits        51476    51490      +14     
+ Misses       9152     9138      -14     

[Samuelopez-ansys]

@SMoraisAnsys Please could you check if the added dependency adds any vulnerabilities?

I think we try to minimize adding new dependencies, mainly for the main ones

[SMoraisAnsys]

@isaacwaldron I can't have a look right now but could you let us know if there are other value to add this dependency except for the read method ? As you know, adding a dependency can add a lot of issues regarding dependencies, maintenance, security, ... So I would rather not add a new dependency if we can avoid it.

For example, we recently found that had a problem to install ansys-pyaedt-toolkit-common due to the combinatorial associated to dependencies installation.

[isaacwaldron]

@SMoraisAnsys @Samuelopez-ansys I don't see any immediate additional benefit unless in the future we decide to add more DXF-focused features that require manipulation of these files. I decided to go ahead with ezdxf partly because of its limited impact on the existing install. Versus a vanilla pyaedt install it only adds itself and pyparsing and the latter is already required by the pyaedt[all] install so it's only adding itself to that install. In addition, while I'm sure you have additional checks that you would do, it at least passes pip-audit.

I can relatively easily revert the addition if we prefer not to add the dependency.

[SMoraisAnsys]

@isaacwaldron Thanks for the feedback, I'll have a better look on this potential dependency. @Samuelopez-ansys Let us discuss next week on that subject as I don't know much about how deeply we leverage DXF in pyaedt.

[Samuelopez-ansys]

@isaacwaldron I have pushed a few modifications, please take a look and let us know if you think this could impact your workflow

[Samuelopez-ansys]

LGTM

[SMoraisAnsys]

Agreeing with Samuel's changes. We don't expect many people needing this dependency so I would prefer not having it as a default dependency of PyAEDT.
We'll discuss on creating groups of dependency that make more sense in a near future.
Could you see the changes and let us know ?

[isaacwaldron]

@Samuelopez-ansys @SMoraisAnsys the customer reporting this has previously complained about the install weight of PyAEDT, which resulted in some of the current libraries in all being removed from the base set back when this originally happened. I welcome additional discussion on dependency groups but for now I think restoring the original custom approach with a modification to support the DXF R12 layer table is best since we do not want this in the base set.

[SMoraisAnsys]

@Samuelopez-ansys @SMoraisAnsys the customer reporting this has previously complained about the install weight of PyAEDT, which resulted in some of the current libraries in all being removed from the base set back when this originally happened. I welcome additional discussion on dependency groups but for now I think restoring the original custom approach with a modification to support the DXF R12 layer table is best since we do not want this in the base set.

Is the problem of installation associated to dependencies or to the PyAEDT repo itself ? I don't think we have that many dependencies in all tbh. Note that ezdxf would come with numpy at least.
On the topic of dependencies feel free to provide any feedback on sets / subsets of dependencies that could make sense. I plan to try following https://peps.python.org/pep-0735/

[isaacwaldron]

@SMoraisAnsys the customer's concern originally was that libraries like matplotlib, pyvista, etc. were in the base set but if you are not planning to do any plotting this significantly increases the download and install weight.

[Samuelopez-ansys]

The user can still do:

pip install pyaedt
pip install ezdxf

And it will work with a minimum size of venv.

Right now, we can not add ezdxf to the basic dependencies of PyAEDT, because we are trying to minimize it (if possible).

[SMoraisAnsys]

@SMoraisAnsys the customer's concern originally was that libraries like matplotlib, pyvista, etc. were in the base set but if you are not planning to do any plotting this significantly increases the download and install weight.

Makes sense. We'll probably move to having a all target with everything and a subtarget being plot for example.

[SMoraisAnsys]

I didn't check but I assume that old_dxf.dxf is R12 format. Can you rename the file so that we can know that from the file name ?

[Samuelopez-ansys]

LGTM