Hey Meltano Team, It seems the target-csv https://gitlab.com/meltano/target-csv/-/blob/master/config.sample.json#L1 in Meltano do not support “destination_path”, which is supported in the Singer Target: https://github.com/singer-io/target-csv/blob/master/config.sample.json. How are you planning to maintain the taps and target in your repository separate from the Singer IO? Was not the idea to benefit from the Singer Taps and Targets?

Hi Rahul 🙂

Was not the idea to benefit from the Singer Taps and Targets?

Definitely! We'd rather not fork any taps or targets at all and use the existing versions supported by the community (or in the case of those in the

singer-io

GitHub org: the Singer team/people at Stitch). In this case it looks like we forked it because it was incompatible with

tap-salesforce

(https://gitlab.com/meltano/target-csv/-/issues/1), and while we submitted that bug upstream as well (https://github.com/singer-io/target-csv/issues/14), we presumably wanted to fix it in Meltano right away without having to wait for Singer to accept our fix (https://gitlab.com/meltano/target-csv/-/merge_requests/1) into their repo and release a new version. About a month after we fixed it in our fork, the fix in the original repo was released as well (https://github.com/singer-io/target-csv/pull/18, https://github.com/singer-io/target-csv/releases/tag/v0.3.0) so there's no longer a need for our fork of

target-csv

to exist at all. In general, these forks should be short-lived and be cleaned up when the upstream catches up, but it looks like we neglected to do so in this case. I've created an issue to deprecate our fork and change the

pip_url

for

target-csv

back to

git+<https://github.com/singer-io/target-csv.git>

so users benefit from the latest changes, including the new

destination_path

setting you mention: https://gitlab.com/meltano/meltano/-/issues/2197