Input feature

[Korusuke]

The functionality to be added is most probably in upt itself and not in upt-macports.
It is inspired by cpan2port, so basically instead of just passing one port at a time we can have below two options:

• upt package -f .. -b .. pkg1,pkg2,pkg3
• upt package -f .. -b .. -i/--input pkgs.list

So here pkgs.list is a file containing package name.

What are your views on this ?

[Korusuke]

• upt package -f .. -b .. pkg1,pkg2,pkg3

Doing this was much easier than I expected, with only difference in actual command being " "(space) instead of ","(comma) which in my view is better.
Will work on file input once confirmed that we would like that option.

Should I create a PR of this in upt repo?

[Steap]

So, what exactly is the use case here? Was it brought up by @reneeotten or @mojca?

One (obvious) issue here is: what happens if you are using stdout as the output file? Will you end up with a few package definitions printed on your terminal, one after the other?

[Korusuke]

So, what exactly is the use case here? Was it brought up by @reneeotten or @mojca?

One (obvious) issue here is: what happens if you are using stdout as the output file? Will you end up with a few package definitions printed on your terminal, one after the other?

I had added it to the proposal as its a feature in "cpan2port" and cause instead of executing again and again for different packages we would have to write the prefix part "upt package -f .. -b .. " everytime.
Instead this provides a better option.

Yeah agree that issue is there, but speaking from macports point of view, I would say almost all maintainers would use the output feature and maybe we should even default to it for macports like if no output arg is given the create a ports folder in the current directory.

[Steap]

OK. Please create a PR in the upt repo. There might be some changes in how the command line works (see #28 (comment)), so I may have to rework your patch, though.

[reneeotten]

If such an "input" option is easy to implement I have no objections against it (it is indeed present in cpan2port but that's not necessarily a reason to implement it here as well). For sure, the "recursive addition" feature is way more important and I conjecture that this might have been the usage of the "input" previously. If adding packages in a recursive fashion works automatically I don't see a real use-case for the input feature; but I have been wrong many times before so perhaps there is ;)

[Korusuke]

Should we close this issue as we are not implementing input feature anymore?

[Steap]

Yeah, let's close it. This is a weird use case. We can always reopen this later, and in the meantime it's easy to work around this using a shell script :)