Switch 3D models to relative paths to improve portability

[vk2diy]

Great software!

This pull request changes only two lines, in order to construct relative paths for both STEP and WRL format 3D models.

This improves portability by ensuring that copied library contents will continue to function.

The use case would be, for example, generating a footprint and 3D model with JLC2KiCad_lib and then copying the resulting model to an existing (eg. project-specific) KiCad library.

Additionally, this ensures that potentially privacy sensitive information such as local paths (which may divulge information such as usernames, dates, project names, etc.) is not accidentally shared.

[TousstNicolas]

Thanks for your PR.

For a project-specific library, I have added the -model_base_variable argument, which allows you to define the model's path using a KiCad variable. In my opinion, this should always be used when multiple people are working on a project.

Wouldn't this address the issue you're trying to solve here?

Additionally, the changes you made would simply break this feature.

[vk2diy]

OK so let's zoom out to generally agreed philosophy for good software architecture.

Purpose, assumption and composability

I think it's fair to say that the primary function of the library, judging by the name of the project and the core functionality provided within the tool and not elsewhere, is that of external resource to local Kicad-format resource conversion.

However, it seems from your reply that you may be asking users to use your conversion software as an internal workflow tool.

Without judging this, the unix mentality is that each tool should do one thing and one thing only. This helps to segregate responsibility cleanly across software by creating simple, well defined interfaces and additionally allows for "composability", or combining multiple tools in to larger workflows. If we can agree with that philosophy, then baking-in assumptions regarding workflow subsequent to the conversion step is probably not a good idea as it runs counter to the unix philosophy. Basically, those assumptions are not going to apply to everyone who wants the conversion feature.

Fundamentally, it's sort of like assuming everyone who orders café also wants a croissant, and not an assortiment de fromage. (I'm more of a fromage guy myself, at least after breakfast, and sometimes only have coffee!)

Always use relative paths

The reason that git and other RCS/VCS solutions work so well across disparate software and software artifacts is that they use a known and relatively simple abstraction (the filesystem) which is shared and provides a clear distinction between those artifacts and versions thereof.

The reason that we almost always default to using relative paths is that such an approach provides portability.

For examples of this philosophy see for example:

• Every RCS/VCS system ever (cvs, svn, hg, git, etc.)
• Every archive format ever (tar/zip/rar/whatever) - though absolute paths may be an option they are rarely encountered

Absolute paths are generally discouraged because:

• They break portability
• They can leak information (and this can have security implications)
• They can have additional security implications in certain tools and processes in terms of escaping from defined work trees and overwriting system files, etc.

Basically, absolute paths represent an undocumented and potentially dangerous assumption regarding the environment in which a file will be eventually used.

Finally, such an assumption is fundamentally incompatible with modern software development in which we should assume that no two workstations have identical configuration and that all projects will be utilized in unknown environments across time and space unless explicitly configured otherwise (eg. wrapped in a container or VM).

Practical demonstration of the negative aspects of the feature under discussion

I have not tried the feature you suggested however I would like to demonstrate for you why it represents a practical problem for certain workflows.

Let us assume that the user:

• wishes to convert a number of parts to KiCad format using your library.
• perhaps wishes to deploy these parts in to a certain KiCad project that is open to evaluate them in some way (eg. footprint compatibility, mechanical size, etc.) but then potentially deploy them to more than one project
• perhaps has an existing internal parts library that is shared across projects (for manageability) or perhaps uses a parts library per project or perhaps some mix of these two options

I would suggest that these assumptions are fair and reasonable.

In this case, there will be a number of conversion events in rapid succession during parts selection and evaluation.

Additionally, during these conversion events it is unclear which projects, if any, will actually wind up using the parts.

In this case, it would not be possible to populate the named argument of the feature you suggest.

At best, it would be populated with a temporary project name during evaluation, and then conversion events would be duplicated for each future project using the component.

This is clearly inefficient.

A better workflow would be a single conversion, then - subsequent to component evaluation and selection - copying to the existing internal parts library or project libraries or whatever other destination is appropriate for the user. This is possible if your software outputs relative paths and does not assume a 1:1 relationship between a conversion event and a named component library.

I think you can see from this explanation that a relative path is far more portable and useful than mandating a component library name be specified at conversion time as it does not embody forward assumptions about workflow, project-component use mapping, or any forward assumptions about project names, project library relationships or component library structures.

Conclusion

Perhaps consider:

• Questioning the utility your assumptions around the feature you have implemented which you said would break by switching to relative paths
• Sticking to doing one thing in the software (and doing it well)
• Avoiding any use of absolute paths, period

In this way you will guarantee portability, reduce undue information leakage, and enable the use of your software within more complex workflows ("composability").

Thanks again for very useful software, I hope you can see the logic here, it took some time to write.