Skip to content

Conversation

@polyfloyd
Copy link

I'm trying to set up a workflow with multiple importers, one of which is a fall-back that matches kind of PDF document.

There currently is not really a way to achieve this, since beangulp does not permit multiple importers to be able to import a given file.

To work around this, I can create multiple distinct importer scripts. But these should then be able to tell whether they are able to process a given file. I think the most common way for this is to set an exit status, which is what this patch proposes.

The status being set is 100, which is distinct from any other error. The exit status is only set of no importer is available for any of the specified files,

@dnicolodi
Copy link
Collaborator

I'm not sure I understand how your cascaded import script are supposed to work and how a specific exit status may help there. Can you provide more details? The way I would do it is to have the more specific importers run first and archive the processed files (to a temporary location that gets removed at the end of the import process, if you don't want to keep them around), to leave only the unmatched ones to be processed by the generic importer. Running the generic importer when no files to be handled are left is not an error. On the other hand, the proposed change cannot tell you if the more specific importer matched some files, but other are left to be handled by the generic importer.

Making the case where there are no source documents to be imported into an error is a breaking change that I would like to avoid. The choice of 100 as exit status is particularly bad as conventionally high exit statuses are reserved for system error conditions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants