If you want to see what a package has done, then yes uSync will capture any new datatypes, doctypes etc that a package might create - they will be stored in the uSync folder.
if you mean can i use usync in a package, then the short answer is no
The longer answer is sort of but it's not this version of usync*:
The current version of usync is very much welded to the folders that are used to import and export things, so everything has to be in the usync folder to go in.
I have a couple of experimental versions on usync that separate out syncing of stuff from the writing to disk, and this version can then be used in things like packages, so you could install a package and then use this modified usync to import things.
In general you don't need to do this because the package manager will bring things in, but it doesn't do things like ID mappings which uSync does, so a usync import works better for certain doctypes and content which is especially useful for a starter kit - this is how the LocalGovStarter Kit brings in content as part of a post install screen where the user gets to pick the content.
*all this is caveated as the version of uSync isn't the live one, and I am working on a extensively updated version of uSync that has all this stuff in but it's not quite ready yet.
I actually meant the former - but it's also useful to know the latter :-)
I'm trying to work out if we can trust a git check in of files + uSync to make sure the package installs stay in sync across dev / build machines.
It sounds like changes to doctypes and datatypes will get tracked correctly - does that cover everything a package install could do to the database do you know?
uSync package installs
This is a bit of a long shot - but is it possible to use uSync to track database changes from a package install?
Hi,
It depends on what you mean.
If you want to see what a package has done, then yes uSync will capture any new datatypes, doctypes etc that a package might create - they will be stored in the uSync folder.
if you mean can i use usync in a package, then the short answer is no
The longer answer is sort of but it's not this version of usync*:
The current version of usync is very much welded to the folders that are used to import and export things, so everything has to be in the usync folder to go in.
I have a couple of experimental versions on usync that separate out syncing of stuff from the writing to disk, and this version can then be used in things like packages, so you could install a package and then use this modified usync to import things.
In general you don't need to do this because the package manager will bring things in, but it doesn't do things like ID mappings which uSync does, so a usync import works better for certain doctypes and content which is especially useful for a starter kit - this is how the LocalGovStarter Kit brings in content as part of a post install screen where the user gets to pick the content.
you can see how that works in the github repo for the starter kit, so it is possible,
*all this is caveated as the version of uSync isn't the live one, and I am working on a extensively updated version of uSync that has all this stuff in but it's not quite ready yet.
Thanks so much Kevin!
I actually meant the former - but it's also useful to know the latter :-)
I'm trying to work out if we can trust a git check in of files + uSync to make sure the package installs stay in sync across dev / build machines.
It sounds like changes to doctypes and datatypes will get tracked correctly - does that cover everything a package install could do to the database do you know?
Andrew
the only thing you have to be concerned about is if the package does any custom db stuff (so creates its own tables or some such.
Most packages don't but you need to just check if you want to use usync to keep things the same.
is working on a reply...