Thanks for those advises, Andrew To tell you a bit more about my context, I'm working on an end-to-end data science projets, which is: - using 90% of python, but also different things - those thing are sometimes impacting system configuration - there's a development accounts, I'm working there without any need of setup.py, compilation, whatever: I run what I develop, period. This includes also cython code, which is compiled on the fly. - commits are on svn - corporate policy - deployment on production servers is a dedicated script, copying on prod users and servers via ssh, and automatic restart of what's needed - ... - for all those reasons, I have no use case for setuptools until now
So, yes, I must admit that I only know the basis of setuptools and I'm a newbie with git. But, well, everybody has something to learn. 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. I just hope that I won't have to spend days on adapting my workflow, but well, that's life. [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] Best regards Le sam. 24 août 2019 21:40, Andrew Barnert <[email protected]> a écrit : > 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/3WKG6O325GM5KEPPZJDGLAFTMMNFUEX7/ Code of Conduct: http://python.org/psf/codeofconduct/
