eping just snap.Validate as the public interface, and making everything else be either in snap/validate or private in snap?
<mborzecki> Chipaca: the motivation was to not have another copy of ValidateName() in asserrts, but rather have a package slimmer than snap and have it importable in asserts
<Chipaca> ha, now i understand the no-spdx thing more :-)
<Chipaca> mborzecki: this strengthens my last suggestion above
<Chipaca> i think
<mborzecki> Chipaca: hm, let me check again, iirc snap.ValidateLayout may still need to be public, but the rest could be make private
<Chipaca> grep says nothing uses it outside of snap.Validate
<mborzecki> Chipaca: ValidateContainer is probably the only func other than Validate() that would need to be public
<mborzecki> i see some calls to ValidateSlotName() but that would be validate.SlotName() (or validate.Slot()) now
<mborzecki> Chipaca: yeah, snap/validate seems ok, a question about naming, since the validation code is mostly validating names right now, validate.SnapName() feels more fitting than validate.Snap(name string)
<mup> PR snapd#6019 opened: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
<pedronis> Chipaca: the problem of making it validate that it will be very tempting to move Validate itself or other things into it at some point
<pedronis> Chipaca: also there are some name related regexpes that asserts could reuse
<pedronis> Chipaca: making it about names (which are strings in the end), makes it easier to keep under control imo
<mborzecki> snap/validate/name :)
<pedronis> that is not funny
<pedronis> Chipaca: mborzecki: anyway my 2cts
<mborzecki> pedronis: which regexp you'd like to see public?
<pedronis> mborzecki: asserts has at least a validAppName and validAlias atm
<pedronis> degville: hi,  somebody liked this just now which Â I wrote long ago,  https://forum.snapcraft.io/t/the-meaning-of-classic/861 is not under doc because niemeyer said he wanted to tweak it a bit but didn't get to it, maybe you can d