Indeed. I usually do a workflow which makes my needs compatible with the standards, but I've started this when I was a python beginner.
I'm aware since months that I should use setuptools, but it was not on my priority, because that bad decision had no impact. Now, time to change had come... Maybe one suggestion: I think it would be great to document it as a limitation in argparse. Don't you think? Regarding a "patching lib", I don't plan to add anything to pip until I found a portable solution. Sorry if my message was incorrect. Thanks again to everyone. Le sam. 24 août 2019 23:20, Andrew Barnert <[email protected]> a écrit : > On Aug 24, 2019, at 13:16, Michael Hooreman <[email protected]> wrote: > > > > I'll consider what you say, and try to understand what entrypoint is. I > have understood entrypoint as a wording for an entry point (main) script. > Sorry. > > Well, it _is_ that, but the point is that setuptools can auto-generate > those main scripts for you, without making you rearrange any of your code. > Which is very cool, and it’s a shame more people don’t know how to use it. > > > I just hope that I won't have to spend days on adapting my workflow, but > well, that's life. > > In your case, hours adapting your scripts to munge the usage output might > well be a better use of your time than days learning a new tool and > adapting your workflow to it. > > That doesn’t mean we should necessarily change the stdlib of Python to > encourage more people to build workflows like yours in the future instead > of more easily-manageable ones. But it does mean that if a lot of people > are already in your situation, and there’s something that would help all of > them, a change could well be worth doing. That’s why I responded > specifically to your proposal, and only added the stuff about setuptools > entrypoints as an afterthought. > > Your proposal might well be useful—but not if it breaks all POSIX systems > but Linux, gives a prog that isn’t usable as a prog, etc. I raised those > issues to see if you have a solution (or if anyone else does). > > > [Private joke] > > I must say that I find disappointing to receive a "tell me what you > need, I'll explain how to not need that". We are all IT guys, and I also do > that. Now, I see what it is from the other side of the court :-) > > [End of private joke] > > Personally, I generally try to explain “Here’s how to do that” before > “Here’s how _not_ to do that.” Especially since “Here’s how to do that” > often illustrates what a huge pain it is to do that, which convinces people > better than just saying “Don’t do that.” :) But in this case, you already > had a solution to offer, so it’s not really the same thing. >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/HMX23KWRNLKXIIJUV2MVP4OJ67WPWFFK/ Code of Conduct: http://python.org/psf/codeofconduct/
