kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Wed, Jan 13, 2016 at 11:06 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 1/12/2016 5:02 PM, Bernhard Stegmaier wrote:
> > Hi,
> >
> >
> >> On 12 Jan 2016, at 22:20, Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx
> >> <mailto:cirilo.bernardo@xxxxxxxxx>> wrote:
> >>
> >> Having a single reference point is extremely inflexible - how do you
> >> handle user models? If a
> >> package manager installs the files and you add to the directories then
> >> your changes can be
> >> overwritten later. If the directories are read-only then the user
> >> can't add models. Some people
> >> use ${KIPRJMOD} or other environment vars in the model names to work
> >> around the current
> >> limitations. Even if we had a scheme like fp-lib-table different users
> >> will have to create
> >> corresponding nicknames on different installations.
> >
> > Is it really?
> >
> > I didn’t exactly follow what you plan, but looking at fp-lib-table:
> > Every user has his own fp-lib-table… either referencing the system
> > libraries, maybe github libraries, or his own custom ones.
> > A user can pick system-libraries he wants from system path and his own
> > ones from some location he has write access and the system package
> > manager won’t overwrite (his home folder I guess).
> > How libraries are referenced in fp-lib-table is pretty much on behalf of
> > the user.
> > He can use pure absolute paths or some other base referenced via some
> > environment variable (don’t know at the moment if it is limited to using
> > ${KISYSMOD} or you can use an env variable that is defined).
> > Using such a variable I can customise my various installations by just
> > setting the local variable to the right path where my (local/private)
> > models are.
> >
> > So, for me this looks quite flexible?
> > At least, it allows me to open *my* projects on different machines I
> > work on with the same (my) library but maybe different filesystem layout.
> >
> > My point is not about exchanging projects between different users on
> > different machines.
> > Of course, if I open a (foreign) project which references 3d-models
> > other than those I have, they won’t be found.
> > But I don’t see any reason why this should be better when using relative
> > paths…
> > When exchanging projects, as you said… either projects have to be
> > completely self-contained or all parties have to use the same libraries
> > (or, model directory structure).
> >
> >
> > Regards,
> > Bernhard
>
> Bernhard has described perfectly described why fp-lib-table is far
> superior to any path list look up table irregardless if the path is
> absolute, relative, and/or expanded from an environment variable.  This
> is exactly why it is designed this way.  I have three different
> platforms that have the same library nicknames appropriately configure
> for each platform.  The footprints in my projects are completely
> portable between platforms.  The same cannot be said of my 3D models
> unless I define $KISYS3DMOD.  The other problem with using paths is you
> have now limited yourself to files on your system.  I can think of a lot
> other places that 3D model byte streams might come from besides a file
> residing on my system.  Using paths and files is very limited.
>
>
I'm really confused now because (a) each user has to set the appropriate
nickname/path to use another person's project file anyway, (b) there is no
assurance that different users haven't chosen a particular nickname -say
'mypath1'- to point to different base paths, in which case someone has to
make changes to a project file received from someone else anyway, and
(c) fp-lib-table allows the liberal use of env vars anyway so that doesn't
get
us away from env vars either. In short: it's not clear to me (a) what issues
people are thinking they want resolved and (b) how any of the proposed
solutions address the issues.

No matter what solution we settle on it will always be trivial to come up
with a case which will cause the scheme to fail, so I favor the following
priorities: (A) ease of the user to configure/use 3D models on their
system, (B) ease of collaborating on a particular project within an
organization, (C) sharing projects between random people.

A scheme similar to fp-lib-table may be helpful but I would not use the
fp-lib-table scheme as such, primarily because that uses one entry
per directory and the user will quickly be swamped by a gazillion
3D paths to choose from.

A brief description of the current situation: 3D models may have an
absolute path, a path relative to the current dir (using "../"), a path
relative to KISYS3DMOD, or a path relative to a random env var in
cases where users have edited a footprint and associated a 3D
model using an expression like ${MYPATH}/a_subdir/model.wrl

So we would like to ensure that the legacy behavior works correctly -
this is already accomplished in my branch except for the case which
NickOE mentioned where 2 different paths may have different base
paths but the same relative path.

Now additional issues come up because we more or less universally
agree that the legacy behavior is broken and must be changed. The
questions we must answer are (a) what are these issues and (b) how
can we address them?

Looking back at the priorities (A), (B), (C), I believe (A), and (B) can
be mostly resolved by using a system similar to fp-lib-table except
that the entries specify a base path rather than a full path of a
directory containing models. So for example:

"mypath1", "/home/user/kicadlibs/3dpackages", "KiCad official 3D models"
"mypath2", "/home/user/others/3dpackages", "My random models"

let's say both of those paths happen to have a 'foo/bar.wrl' - this will
now be represented in the pcb file as  [^mypath1^]/foo/bar.wrl and
[^mypath2^]/foo/bar.wrl

So now the file can be uniquely resolved for a specific user under the
assumption that the user doesn't change the values of mypath*
to point to different model sets and then revisit an old project.
Only a single base path is needed to represent each model dir tree;
you are guaranteed of course that paths relative to that base are
unique. Using a base path to a model dir tree of course allows us
relatively easy access to many thousands of models without
creating dozens of base path entries as would be required if we
used a scheme exactly like fp-lib-table

For (B), the collaborators can agree on policies etc to ensure that
there are no problems. This is a matter beyond the scope of kicad
software. For (C) possible solutions include (1) the various users
must coordinate (sure), (2) we provide some function within
kicad which ensures a local copy of all data required and changes
internal data to use that local copy, and (3) because of the work
involved with (2) treat this as Not Our Problem and simply let
users employ (1) until such a time as we're inspired to provide a
more convenient option.

Of course it's trivial to imagine ways in which this scheme can fail
but it is more robust than the existing scheme and addresses the
various ways in which 3D model names are currently resolved while
providing a more convenient interface for users and putting us on
the path to discouraging the use of ${ENV_VAR} in the model names.
Of course we *can* do:

"mypath3", "${ENVVAR}", "My random envvar dir"

and this should work, but such use should be discouraged.

As for relative dirs and absolute paths (no known base path),
what do we do? If we are to support legacy files we must
support relative and absolute dirs although this breaks the
aim of (A), (B), and (C). Alternatively we can refuse to support
that aspect of legacy behavior and instead bring up a big
warning (once only - not once per model)  informing the
user that they need to add a suitable entry to the base
path search table.

- Cirilo



> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>