On Aug 24, 2019, at 08:48, Michael Hooreman <[email protected]> wrote: > > Let me clarify a bit. Setuptools and standalone scripts is indeed the > best classical approach, but that does not adapts to my use case. I'm > working with a contunuously, fast evolving system, and there is no > "identified release" (continuous delivery).
So what? You don’t need an identified release to use pip. Let’s say people have to git pull your code every time they want a new feature or fix, and different people are running code dozens of commits behind or ahead of each other or even on different branches. That’s about the worst-case scenario for managing distribution, right? But pip still handles that just fine. Just pip install from the git repo, and you get the latest code (without even having to have a local clone of the repo, or know anything about git). Or maybe you have insane security requirements, and you deliver updates by having armed guards physically hand out USB sticks with today’s code. Again, pip handles that fine; just pip install /dev/stick/path/to/pkg/setup.py instead of cp -a /dev/stick/path/to/pkg ~/local/pkg. And so on. > I'm under the impression that you tell me that I must use setuptools > entrypoint script so, in other words, a "standard executable" script. No, I’m not telling you that you _must_ use it. But I am telling you that you _can_ probably use it, and if you can, it will automatically solve your problem. > But, it this is THE only way correct way to do, why do python allows > __main__.py? This is a silly question. Imagine you were asking how to insert a value into the middle of a tuple, and, after telling you how you can sort of do the immutable equivalent of what you’re asking, I also pointed out that usually when you want to insert into the middle of stuff, you want a list, which makes it trivial to do exactly what you want. Would you demand to know why Python allows tuples when they don’t solve your problem? Of course not. But that’s what you’re asking here. But if you want an answer anyway, I can think of multiple reasons to add and then maintain the -m functionality even though scripts are useful more often. The first one, I already gave you. There are packages where you’re likely to want to run the same thing with multiple Python installations, and which Python installation is important. For example, you don’t want ipython to start a REPL for any random install, you want a REPL for a specific one. You don’t want pip to install into any installation, you want it to install into a specific one. And so on. These packages have to be designed around -m, so you can run python3.8 -m pip or pypy3 -m ipython or whatever. (But notice that most such packages actually still do provide a shortcut script for the convenience of people who only have one installation.) There are also a lot of packages that _can_ be used as scripts but most people don’t. For example, in the stdlib, many people use the json, http.server, etc. modules in their own code; most of them never run those modules as scripts. But a few people do. So, it’s worth making then runnable, but not worth advertising that fact by adding a script in the PATH. There are also packages that are mainly used straight out of the dev tree. For an extreme example, a package that’s needed to run your setup.py build stage had better be runnable before you’ve done setup.py build, and -m is a way to do that. Are those enough reasons why it might make sense for Python to include -m even though it may not be the best answer to your problem? > I don't use standalone script because there are many entry points to my > library, which has a very depth (sub-)packages structure, and on one > hand having dozens of scripts in a ./bin directory lacks of efficiency, > on the other hand I don't want to use absolute imports within a library > just to be able to have standalone scripts, knowing that it is also the > job of __main__.py. OK, I don’t think you know how entrypoint scripts work. (It’s not an easily discoverable feature, so _most_ people don’t know, sadly.) You don’t have to write a complicated script for every entrypoint, you just add an entry to a list in your setup.py file and the scripts get generated at install time. And, even more importantly, you don’t need to change your code to use absolute imports. The generated script imports the entrypoint from its package using the normal mechanism, so it’s still part of a package. And if that package was a subpackage or another package, the entrypoint is still part of a subpackage. And so on. If you really do have dozens of functions that everyone needs to run, you might consider writing a driver that steals the first arg and uses it to decide which entrypoint to call—sort of like the way tools like git work. You can still leave the rest of the argparsing up to each entrypoint if you want (which is a good idea if the separate commands have unrelated APIs—or if you need to be able to run some of the commands out of the dev tree with -m even though most of the people you’re distributing to won’t often do so). But either way, this isn’t done for your automatically—there are third party libs that make it easy, but it’s still not as easy as just adding an entry to your setup.py script—so it may not be worth the effort for your use. >> I don't make a setuptools entry point here for the good reason that this >> is used as part of a system, which is not using standard deliverables. >> You have to consider that they are other uses cases of python than some >> packages to deploy with setuptools. Yes, but many of those use cases actually _can_ still benefit from setuptools, so it’s worth knowing what it can do rather than assuming it’s useless to anyone who isn’t deploying public monolithic releases to PyPI, much less getting angry if someone even mentions using it as a suggestion. _______________________________________________ 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/MNUQOHJEQATGVEZGRT5PNBLLCPGFSNHI/ Code of Conduct: http://python.org/psf/codeofconduct/
