sample feature

[plastikfan]

Allows user to try out multiple profiles in the same batch to see which one works the best. Requires a sample entry in the config which is just an array of string. Each string referrers to a profile

The sample config also needs a number of images to try on (let's default to 3) and a minimum image size in MB (default=1).

For each of the images run the selected profile.

By default, the default directory is the current one. For each file we create a relative path that contains the profile name. The out file name by default s the same as the input file, but this can be changed by a config setting

Actually we can create many more config settings without necessarily creating flags. This will avoid complicating the cli.

---

Some more design notes:

• let's delete the Mode param as it is too vague
• we introduce 2 concepts, the OutputStrategy and DeletionStrategy, each of which will implement an Inline and Mirror strategy. (as we'll see later, they can be mixed with each other)
• The runner is aware of the output strategy moving files accordingly, using the path-finder to create the paths and the file-manager to interact with the file system, using a vfs.
• OutputStrategy(INLINE): the output file(s) are created in the same location as item.Path (but do we create as the original name or as an alternative output name; this would also require renaming the original as required)
• OutputStrategy(MIRROR): the output files(s) are created in mirror path,, but we also re-create the relative directory of the source to implement mirroring
• DeletionStrategy(INLINE): the Trash folder is in the same directory as item.Path
• DeletionStrategy(MIRROR): the Trash is in the a mirrored relative directory under MirrorPath
• Since, the OutputStrategy and DeletionStrategy are independent of each other, they can be mixed and matched as required; ie just because you're using Mirror in one context, doesn't mean you have to use Mirror in the other.
• perhaps we have a transparency mode, ie perform renames such that the new generated files adopt the existing files, so there is no difference, except for the original file would be renamed to something else. With transparency enabled, we make all the decisions to make this possible; we internally make the choice of which strategies are in place, so the user doesn't have to work this out for themselves. But the deletion strategy is independent of transparency, so it really only applies to output. Or, perhaps, do we assume transparent by default and the other options adjust this.
• In scenarios where we need to rename the original file to something else, by default, we append "LEGACY" to the end. This can be configured in advanced settings
• Advanced settings, a new section in config contains settings for which there are no command line flags, as they rarely need to be changed
• the strategies are properties of the path finder as they help create paths depending on usage mode

---

Further tasks:

• duplicant transparency mode #80
• implement sampling non transparent #82
• define tidy up functionality #85

[plastikfan]

found this interesting article about workflow patterns: Control-Flow Patterns.

The reason why I'm considering this, is because I'm looking at the classes required to implement the sampling feature. So far, I have come up with the followng abstractions (the names are not necessarily the ones that will be used):

• Manager/Controller : on the occurence of a new TraverserItem (deleivered by ShrinkEntry), controls how it is handled. IE, it knows the sequence of events that should subsequently occur. For sampling, this is more complicated than a full run, becuase for each new TraverseItem, multiple invocations of the third party command (magick) are required. For a full run, we only require a single external invoke.So it will drive the 'workfow' and in this case means, rename existing file, collating the correct third party args and issuing the command and waiting for the result. (There will be 2 different instances of the controller, 1 for sampling and the other for a full run; these will be hidden behind an interface)
• FileManager : responsible for working with the file system, so will contains the virtual file system reference
• PathFinder : concerned with creating correct paths according to incoming paramters

Actually, the referenced site looks to be very good as it deals with scenarios that I have been wrestling with in various parts of my snivilised projects, but I have dealt with them on an adhoc manner, coming up with my own way of doing things rather that looking at established patterns. This can serve as a very good reference. A lot of these pattarns are relevant for web workfows, but they can be adapted to be used in other contexts too.

[plastikfan]

some temporary code:

func (pc ProfilesConfig) AsCommandLine(name string) cobrass.ThirdPartyCommandLine {
	const approx = 2

	if name != "" {
		if profile, found := pc[name]; !found {
			keys := profile.Keys()
			size := len(keys)
			cl := make(cobrass.ThirdPartyCommandLine, 0, size*approx)

			for flag, optionValue := range keys {
				long := fmt.Sprintf("--%v", flag)
				cl = append(cl, long)

				if !slices.Contains(booleanValues, optionValue) {
					cl = append(cl, optionValue)
				}
			}

			return cl
		}
	}

	return cobrass.ThirdPartyCommandLine{}
}

func (pc ProfilesConfig) WithDashes(name string) clif.SpecifiedFlagsCollection {
	if name != "" {
		if profile, found := pc[name]; found {
			flags := clif.SpecifiedFlagsCollection{}

			for _, flag := range profile.Keys() {
				optionValue := profile[flag]
				long := fmt.Sprintf("--%v", flag)
				flags[long] = optionValue
			}

			return flags
		}
	}

	return clif.SpecifiedFlagsCollection{}
}

[plastikfan]

NB: we can open a folder (on mac), (for pixa, typically the output folder) from the command line using:

open <path-name>

On windows (yet to be confirmed):

start <path-name>

Not sure what the linux equivalent is yet...

[plastikfan]

Need to start using mocking, in this case so we can mock out viper config. Using uber mock.

The first to know, is how to make a mock; here is the documented example (as described in mock_test.go):

mockgen -destination mock_test.go -package gomock_test -source example_test.go

• use -mock_names to specify the interface to be mocked and the mock name, eg:

Repository=MockSensorRepository,Endpoint=MockSensorEndpoint, where Repository is the interface name and MockSensorRepository is the desired mock name

• --source specifies where the source interface is defined, eg:
  -source=foo.go

But actually, this doesnt clearly explain how to mock a foreign interface. I found this: codecentric.de gomock-tutorial, which may be a bit clearer, in particular:

mockgen -destination=mocks/mock_doer.go -package=mocks github.com/sgreben/testing-with-gomock/doer Doer

where:

• mocks: is the name of a package that will contain our mocks (mocks are to be created in a specific mock package)
• there are 2 non flag arguments, an import path, and a comma-separated list of symbols
• in the above example, github.com/sgreben/testing-with-gomock/doer is the import path and Doer is the symbol to be mocked

To make this a bit easier, we should not try to create a mock for a foreign interface as this is complicating the task. Create the mock in CObrass and then export it so it can be resued by clients.

[plastikfan]

Actually, after having implemented a mock for viper config, I realised its better to re-organise the profiles and sampler config. They should be wrapped behind interfaces then mocks should be generated for those. The problem with mocking viper config is that its difficult to re-implement the marshalling when really, we need to by-pass marshalling altogether.

[plastikfan]

this feature looks to be too big to do under a single issue; therefore it will be split up. This issue will deal just with the default scenario, which is transparent mode which means:

• inline mode for output generation and input deletion
• input file moved to local TRASH folder
• output generated in local location including mirror-sub-path and supplement(profile/scheme)