On 2019-01-04 12:56:56 -0500, songbird wrote: > Peter J. Holzer wrote: > > Almost all of these points don't seem to be related to the language, but > > to your environment. > > an application isn't useful unless it actually can > be deployed and used in an environment.
True. But environments are different. And many factors of the environment are completely independent of the language. For example, about 10 years ago I built a continuous integration pipeline for a project I was working on (we didn't call it that - I'm not sure the name had been invented at that time, but the concept is much older). It checked every minute if something had been committed into the master branch of the repository, checked it out, ran the test suite, and if all the tests succeeded, deployed the application on the test server. I also revoked the developer's privileges to install anything directly on the test server. The result was that any change took about half an hour to show up on the server. The software was written in Perl and Java. Was it Perl's fault that the Change-Deploy-Test cycle was so slow? Was it Java's fault? No. It wasn't the fault of either of the languages. It was a combination of the system I've built (which always ran the complete test suite and didn't try to skip irrelevant tests), the size of the project (the test suite was huge and some tests were slow), the components I used (for example, cron can only run a job every minute) and of organizational measures (revoking privileges) I took. Somebody who never used Perl before and encountered our system might say "Perl is bad because it takes half an hour to deploy an application", but that wouldn't be correct. Similarly, when you write that it takes half an hour for your changes to show up, and that you have to clear some caches, that doesn't seem related to the language but to your specific environment. I write mostly web-applications and programs intended to be run from the command line or cron. With Django or Flask, changes usually show up within a second or so in the development environment (I don't even have to restart the server, it restarts automatically when I save a file). CLI scripts are of course also ready to run as soon as I save them. And caches may or may not be a problem but that is application-specific. To deploy my changes (to the test or production environment), a "git pull" plus maybe some other actions is sufficient - again that completes in seconds, not minutes. So we are both using the same language, but I see my changes immediately and you have to wait half an hour. The difference is that we are working in different environments. Now it may be that the tools that Python provides are ill-suited to your environment, and that improving those tools (or providing additional ones) may help you and possibly others. Or it may be that you have to change something in your environment which is completely outside of the control of the Python developers. I'm not able to figure out from your vague and general descriptions whether a change in the Python tool-chain or a change in your environment would help, much less a specific change. > at least these make sense: > > https://packaging.python.org/tutorials/installing-packages/ > https://docs.python.org/3/installing/index.html#installing-index So your problem is packaging? I didn't even figure that out from your previous mail. (Though now I remember vaguely that you may have complained about packaging before. Hint: On a busy mailinglist, don't assume that everybody remembers everything you have written before. Provide enough context in every mail that people know what you are talking about.) I haven't packaged anything yet. I have looked at the documentation several times and I agree that it looks somewhat daunting (I am not unfamiliar with packaging systems: I have built rpm and deb packages, and used both the Makefile.PL and Module::Builder systems for Perl, but the Python docs left me somewhat at a loss - and since I didn't actually need it I postponed learning how to do it). hp -- _ | Peter J. Holzer | we build much bigger, better disasters now |_|_) | | because we have much more sophisticated | | | h...@hjp.at | management tools. __/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
