What’s the best practice for storing stp files and making easy to distribute stp files with footprints to others? Currently I’m just downloading the files and adding the path into the footprint editor but this is storing all the stp files outside of the project/part library making it so that if I commit the footprint to a git repo or send it to someone they don’t have the associated model or path to it. KiCad makes it simple to create new symbol and footprint libraries but I don’t see anyway to make a standardized location for storing user generated/downloaded models that make it easy to distribute. Am I missing something/
I have been looking at this too. KiCad does not treat models like it does the symbol and footprints. You can create a “path” in the path preferences. What i have done is added my own folder locations for symbols, footprints and models. You that then use the path names instead of the full path. So you can create a library folder structure and providing that folder structure is kept intact yau can then put the top folder anywhere you want and the user of the library just needs to create a path with the name you have used and point it to their location.
Even better, the path can be relative to $(KIPRJMOD), an environment variable pointing to the project folder. The user that receives the project must not do anything.
If you like project local libs then yes. If not then probably not the best solution 
Yes i am really not a fan of local libs as i feel it leads to a very bad overall library setup with massive duplication of effort and a maintainance nightmare of epic proportions. In my opinion the few extra seconds of work to make a proper logical scalable central setup are simply worth it in the long run.
I acknowledge “read only” sharing to people who do not intent to reuse your assets at all is a bit harder that way. (Everything but 3d models is very easily done by including the cache lib in the archive. To be honest i would share 3d stuff by exporting the full pcb to step anyways instead of sharing single models of footprints that then require kicad to be looked at as the full pcb.)
what happens if you have custom libraries in the kicad folder and do an update? If I am making custom stuff I prefer to keep it seperate so that i know what is what.
What about for cases where read only isn’t the goal but working with multiple developers who are going to make changes? Project local libraries allow things to be self contained and to not have to add a bunch of unrelated extra stuff. In most cases the symbols and footprints I’m creating are specific to a project that I’m not using in others because I’m typically using the symbols and footprints from the official libraries for most parts.
1 Like
really not a good idea but KIPRJMOD does not point to a kicad directory but to the root of the currently opened project.
If assets are specific to a project then by all means put them into the project directory (see apendix of my tutorial i liked above)
But If you have a personal library of things that are not specialized for a single project then put it into a central location, give it a unique enough name as to not interfere with others and share your global assets together with the project. (It will start with one or two assets and then steadily grow. As long as the lib stays kind of small there will not really be a problem if you do not organize it properly. But there will come a point when you wish you would have made it proper from the first day on.)
If you use git to share your projects then you can use subgit to include the central lib. For svn there are similar tools available.
And if you use e-mail for sharing, well send two archives or get out under the rock and into the cloud 
Sory I thought it was a folder in Kicad itself. I think what the original poster is trying to do is create libraries that are to be used over and over by someone else.
This presumes that all relative paths are equal… Not so in all environments. I think this makes more assumptions about other people’s environments than only using the environment paths. Also the assets that you would need to point to with the relative paths are likely not in the regular distribution, so the recipient of the project would then have to download the assets and put them where you think they should be instead of where it makes sense for them. I think when sharing projects the safest thing to do would be to use something like MitjaN’s archive project plugin. That way all assets for that project would be in the project folder (and this would protect the project against changes in the standard libraries).
For an extreme example, I have some projects deep in Google Docs folder, others deep in DropBox folders, and even others deep in OneDrive folders. (All depends on what organization I’m sharing those projects with.) For me, using the environment variables is really the only sane way to keep things straight, relative paths would be way too cumbersome.
Yes and there are two options for doing it. Central setup with custom environment variables or project local setup using the KIPRJMOD variable. (I prefer the former which is why my tuturial mainly handles that case but as there are legitimate cases for the later i also include it in the apendix)
What I do for myself so I can access my personal resources on any one of my different computers is have my shared assets on an auto-synched folder (e.g. DropBox, GoogleDrive, OneDrive, etc). I use the same variable name for the root of the asset tree and on each computer I have the variable name configured to how that computer accesses the auto-synched folder.
I don’t know how well that would work on a multi-person team where different people may be making changes to the assets at the same time (i.e. synchronization conflicts). For a team, it might make more sense to have the assets in some sort of version control like git or svn (something that requires manual effort to synchronize) or only one person on the team to have permission to make changes. I seem to recall this topic being discussed many times on this forum, and I don’t recall there being one solution that fit well with everyone.
1 Like
Well providing only one person does the edits something like dropbox can work
The OP question was about sharing projects.
The way I share a project is a self contained project.
A folder with subfolders for symbols, footprints and 3d models with all paths related to $(KIPRJMOD).
When more than one person is working on a project stored at github, special care must be taken in order to simulate the “locking” of the files.
Even for the official libs I have a copy in my hard drive different from the proposed directory.
I don’t want problems related to the official libs updates.
But this is only a personal way of doing things. If uselful for someone, is alright; if useless for everyone, is also alright.
Edit: we use different operating systems, so hard paths are not reliable.
Hard paths (i would assume you mean absolute paths) are not used for 3d model assignments no matter if you use project local or centralized setups. (Or at least they should not be used if you plan your assets to be shareable.)
They can be used to fill environment variables which are setup by every user to fit their personal setup. These variables are then used in the 3d path in the footprint. (or in the shared library tables)
Meaning no problem with different operating systems or any other setup difference no matter if you use a local or global setup.
See my tutorials linked above for more details (Including graphical representations of how this works)
1 Like
My way is using the relative path to point to the stp file (it is relative to where the footprint lib file). And always storage stp and footprint libraries together in a repositories. So I can have multiple independence footprint repositories which can be in any combination way for each projects I have. And I do not ever need to worry about absolute path setting in the environment. If all my footprint use same environment variable to a stp file. It force me to store stp files at one central place, and prevent me to made independent footprint + stp sets. I do not worry so much about duplication because that can be organized. And with relative path, we can break footprint into many category and smaller repos as needed without introducing a flooded of environment variable names…
Yeah, for me hard paths are the same thing as absolute paths.
Absolute paths can be used for 3d models. This doesn’t mean I like them, it’s the other way round.
As I said, I explained my way to manage my libraries. I do not use $(KISYSMOD) or $(KISYS3DMOD) at all. Each project has its own libraries related to the project folder so the project can be sent to anybody, libraries included.
My post was not meant to say that you can not do that. More that you really should not do it. (5 minutes of prep work can save hours later on.)