tag:blogger.com,1999:blog-10678074.post6394144725946736773..comments2024-03-28T07:16:45.478+00:00Comments on making apps, making webs.: Gradual Packaging, with python - Part twoUnknownnoreply@blogger.comBlogger8125tag:blogger.com,1999:blog-10678074.post-72548378175335796372022-09-05T13:06:06.104+01:002022-09-05T13:06:06.104+01:00Excellent post. I appreciate your sharing. The CPS...Excellent post. I appreciate your sharing. The CPS test, a free online game, keeps track of how many clicks are made each second. In order to calculate your mouse click speed and generate a result in CPS, you must do a click speed test. Visit this post on the <a href="https://postheaven.net/15mvfz1tub" rel="nofollow">cps test</a> to learn more. <br />Robert Clarkhttps://www.blogger.com/profile/16880021567414102522noreply@blogger.comtag:blogger.com,1999:blog-10678074.post-54239953964047933312022-04-19T14:15:53.507+01:002022-04-19T14:15:53.507+01:00Good night my angel quotes
Short Instagram Captio...<a rel="nofollow">Good night my angel quotes</a><br /><br /><a rel="nofollow">Short Instagram Captions</a><br /><a rel="nofollow">good morning captions</a><br /><a rel="nofollow">Alone Whatsapp Status</a><br />aboutourlifehttps://www.blogger.com/profile/01974393963393919134noreply@blogger.comtag:blogger.com,1999:blog-10678074.post-67671104382004924112017-07-27T05:42:51.758+01:002017-07-27T05:42:51.758+01:00very interesting..nice post.thank you for sharing ...very interesting..nice post.thank you for sharing information..<br /><br /><a href="https://onlineitguru.com/python-online-training.html" rel="nofollow">python online training</a><br />Anonymoushttps://www.blogger.com/profile/04103332849838744096noreply@blogger.comtag:blogger.com,1999:blog-10678074.post-35164024837214865222017-02-08T14:55:43.328+00:002017-02-08T14:55:43.328+00:00Yeah, releasing to pypi is something to consider. ...Yeah, releasing to pypi is something to consider. Pypi can remove packages right? I've removed some anyway... Cleaning up pypi of unused old packages might be useful. However, releasing code to internal package indexes(devpi etc) or just publishing to git/folder/web and referencing that in the requirements is popular already (for internal company use). I've seen teams which just copy their python files into place (ansible, fabric devops people), or just 'release' to their git repos and use links to them in the requirements.txt of other packages. <br /><br />Better support for namespace packages will allow less pollution of the global pypi namespace. That's probably another topic to work on.<br /><br />I like simple_setup (see below) which is a setup.py file which does the gather metadata trick. The benefit of this is that you can point pip at it to install. pbr uses a similar trick to make the setup.py minimal and keep all the logic within itself. I currently think this is a good idea.<br /><br />Testing is a good topic, that deserves a lot more words. I recently tried to run all the tests from the 400 most downloaded packages from pypi. It's pretty much impossible. Even with tox.ini ones, there were plenty of failures - that didn't fail on their travisci. However, with a bit of work I managed to automatically find how to run tests with many packages. Even though there is no standard way to test packages (many don't work with setup.py test). For a pyrelease tool, I would probably pick a convention that is supported, and perhaps use some introspection again. If there is a test_bla.py in the folder, I'd try run it with one of the test runners (py.test), or if there's a test folder, do the same. Picking one tool most likely. If people need more than that, then they'll have to configure the test framework.<br /><br />Running tests for the downstream packages that depend on your package is very useful for catching bugs. It amplifies the size of your test cases by a lot. I know some programs and packages do this already. eg. twisted some years ago asked python to run its test suite before release to lessen the unintentional regressions.<br /><br />---<br /><br />If all the python tools use setup.cfg sections, that will already clean up python repos by 3-10 files. There's already pull requests and patches for tox and mypy, but there is some resistance. They already use setup.cfg to configure some of the tools themselves. (see https://github.com/python/mypy/pull/2761 )<br /><br /><br /><br />Here's a list of tools all aiming to simplify packaging and package management:<br /><br />pbr http://docs.openstack.org/developer/pbr/<br />flit https://github.com/takluyver/flit/<br /><br />(a setup.py which gather info from the environment) https://github.com/braingram/simple_setup<br /><br />pypackage https://github.com/ccpgames/pypackage<br /><br />pipenv https://github.com/kennethreitz/pipenv/<br /><br />fades https://github.com/PyAr/fades<br /><br /><br />(It's interesting to me that some of them come from a user group, a games company, and a microservices group with hundreds of python packages, and the 'for humans' guy).René Dudfieldhttps://www.blogger.com/profile/17762358075557755436noreply@blogger.comtag:blogger.com,1999:blog-10678074.post-51154238095377094962017-02-08T14:55:11.599+00:002017-02-08T14:55:11.599+00:00@Paul, thank you very much for the discussion.
A ...@Paul, thank you very much for the discussion.<br /><br />A few random thoughts below. The most important and easy win I think is convincing a couple of tools to support using setup.cfg sections for configuration.<br /><br />---<br /><br />Many tools now use setup.cfg sections. The holdouts are mypy, pylint, and tox. But 11 or so other tools do apparently (flake, coverage, pytest, etc). I'd like to advocate for at least the python tools supporting setup.cfg.<br /><br />It's quite easy to parse python files without executing them. As long as people don't do tricky things that is. If they do tricky things, then the tool should be able to fail with an error, and prompt people to use. __version__ __author__ and __license__ are quite common already.<br /><br />I'm not entirely convinced myself that pyrelease should be a thing. Or if the 'gather meta data' idea is a good thing. However, I'd like to try and continue looking at how far the idea can go. Perhaps it would work nicely combined with ideas from flint, pypackage, sphinx-quickstart and others.<br /><br />For version, they live in pypi already. At packaging time, the simplest way would be to just increment what you get from pypi. Of course __version__, and git tags could be supported too.<br /><br />.py files don't really have a tool for managing them at the moment. It would seem a package management tool could support them. They technically require no meta data.<br /><br />pylint and other tools use per file config. Might be nice to standardise this somehow. Not python constructs but comments.<br /><br />Yeah, flint with one config file could be easily used by many.René Dudfieldhttps://www.blogger.com/profile/17762358075557755436noreply@blogger.comtag:blogger.com,1999:blog-10678074.post-24258175425874261492017-02-08T14:54:37.189+00:002017-02-08T14:54:37.189+00:00@Scot! Happy to collaborate on things. (your comme...@Scot! Happy to collaborate on things. (your comment got flagged as spam for some reason)<br />René Dudfieldhttps://www.blogger.com/profile/17762358075557755436noreply@blogger.comtag:blogger.com,1999:blog-10678074.post-68085510250631044722017-02-08T13:46:31.867+00:002017-02-08T13:46:31.867+00:00Nice article. I see where you're coming from w...Nice article. I see where you're coming from with the idea that we should be able to publish single file modules. However, there are a few things that bother me still. First of all, while having version numbers, package descriptions and the like in the code is nice in the short term, IMO it's not sustainable in the longer term. First of all, you can't introspect the data from the module without executing the module, and that's a potential problem (less so for a developer tool than for pip, though, so probably OK for pyrelease). Secondly, the needs of your docstring and your long_description diverge fairly quickly - you may want ReST markup in the long description, but (mostly) plain text in your docstring.<br /><br />Honestly, I'd rather the minimum be the code, plus a single config file containing the metadata. There might be a (tiny) bit of duplication, but the benefit of a clear separation between information about the module and the module itself, would be useful IMO.<br /><br />I wonder - from what I've seen, flit is a nice lightweight packaging tool that is based on this "code plus a single metadata file" idea. So maybe having pyrelease just generate a flit.ini file for your project is what's needed here.<br /><br />One thing I am a bit bothered about, though, is the "it's easy to rename" idea. I know where you're coming from (most of my modules start out named test.py!) but naming something <b>for release</b> is a big deal. You're reserving a name on PyPI forever. That really shouldn't be something you do without thinking.<br /><br />I'd also be interested in where you'll go with regard to testing (which tool? use tox?) and CI (travis and appveyor *need* their own config files, you can't avoid that). And maybe even documentation (you really can't last long with "read the source file"). This sort of question is what prompted me to start the PyPA sampleproject - and it got dreadfully bogged down because there genuinely is no consensus on any of these things :-(<br /><br />But regardless, thanks for working on this. "How do I set up my environment to build my shiny new idea in Python?" is a very common question, with no (or rather too many) good answer, and we really need something better.Paul Moorehttps://www.blogger.com/profile/17557923197983461835noreply@blogger.comtag:blogger.com,1999:blog-10678074.post-78209783088681857402017-02-08T01:40:26.391+00:002017-02-08T01:40:26.391+00:00Hey, I really liked this post. I honestly couldn&#...Hey, I really liked this post. I honestly couldn't agree more about the state of simple package management, and I think your tool would certainly be helpful for many people (me included).<br /><br />I recently made a tool (trabBuild) to help me with simple packaging. In fact I used it to package and upload itself to PyPi right after I read this post! <br /><br />My next step with the script was to implement something similar to what you already have here. I checked out your code and I think we might be able to merge some of this together and save a fair amount of work.<br /><br />Links to code:<br />PyPi: https://pypi.python.org/pypi/trabBuild <br />GitHub: https://github.com/Duroktar/trabBuild<br /><br />Thanks again!Anonymoushttps://www.blogger.com/profile/09766344434373160414noreply@blogger.com