the python name

[Peter J. Holzer]

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
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20190106/ec6f314f/attachment.sig>