<div dir="ltr">I see a lot of talks about setuptools/no setuptools/distutils<div>and let me (as usual) state my opinion that all of that is</div><div>wrong. Instead of discussing who will write the code (which</div><div>is essentially the root problem) how about just setting the</div><div>data processing requirements and cover them with tests</div><div>and stories?</div><div><br></div><div>Ship supporting infrastructure that allows people from</div><div>Fedora, Debian, Anaconda see HOW DATA about packages</div><div>is managed and adopt their tools to support Python style.</div><div>This will save us all a lot of effort in maintaining the stuff</div><div>between different systems. As you may see - PEPs are</div><div>good, but not effective. The testsuite that you can download</div><div>and test your tools against - that would be awesome thing</div><div>both for tool development and for LEARNING Python.</div><div><br></div><div>Why learning is here? Just a simple data definition is not</div><div>enough - you need to understand why the data structure is</div><div>there in the first place - for what story it is made for? And</div><div>when you have the story and the data - it is everything that</div><div>is needed for a practical Python lesson about how to</div><div>process files and data formats.</div><div><br></div><div>Stories are scenarios. My usual scenario is:</div><div><br></div><div>- install files from a package into local python</div><div><br></div><div>When you think in data centric way, do you need to know</div><div>the files that you need to copy from a package into local</div><div>Python. Yes. But do you need a data format for that into?</div><div>If you're using wheels - no. Because there are no</div><div>needless flies. If you're using .rpm? Yes, you need to</div><div>parse and exclude .spec files etc. Every author may</div><div>choose their own input - we just define the common</div><div>output.</div><div><br></div><div>- uninstall files from local python</div><div><br></div><div>Here you need the list of files. Where do you get it from?</div><div>From some custom specific format located in a directory</div><div>named after some complicated calculated that is</div><div>separated over separate PEPs that requires a separate</div><div>module to calculate. You see. It is where everybody in a</div><div>trap of using setuptools, distutils etc. I just want to query</div><div>static data - "give me all files for this package" or</div><div>"give me all packages with this name so that I can</div><div>choose specific versions". What should be the data</div><div>layout to allow that?</div><div><br></div><div>- create isolated virtualenv from existing files</div><div><br></div><div>I am pretty sure it is not possible now and everybody</div><div>is redownloading the stuff again and again to create</div><div>new environment.</div><div><br></div><div>- check all my installed modules for security issues</div><div><br></div><div>- check all my virtualenvs for security issues</div><div><br></div><div>The last part requires a place for virtualenvs to register</div><div>their location, so that you can read their modules and</div><div>give security warning about them too.</div><div><br></div><div><br></div><div>With test coverage (and beautiful and easy runner) this</div><div>will allow people to write final tools in a fun way. And if</div><div>people have fun, they usually create better things than</div><div>those who are forced to do their thing for a living. And it</div><div>will be more fun if they can easily extend tests for new</div><div>stories.</div><div><div><br></div>-- <br><div class="gmail_signature">anatoly t.</div>
</div></div>