[Python-ideas] Timer that starts as soon as it is imported

[Andrew Barnert]

On May 27, 2015, at 04:30, anatoly techtonik <techtonik at gmail.com> wrote:
> 
> On Wed, May 27, 2015 at 12:43 PM, Andrew Barnert via Python-ideas
> <python-ideas at python.org> wrote:
>> On May 27, 2015, at 02:00, Chris Angelico <rosuav at gmail.com> wrote:
>>> 
>>>> On Wed, May 27, 2015 at 6:50 PM, anatoly techtonik <techtonik at gmail.com> wrote:
>>>> How do you make these importable? Do you git clone it from site-packages?
>>>> Like:
>>>> 
>>>> cd site-packages/
>>>> git clone .../shed .
>> 
>> Or just build a trivial distribution out of it and then you can just "pip install git+https://github.com/you/repo".
> 
> But that would make it nested under the "repo" package namespace, no?

That depends on how you write your setup.py. It can install a module, a package, three separate packages, whatever you want. I just install one flat module full of helpers (plus a whole bunch of dependencies).

> If not, then how pip detects conflicts when the same file is provided
> by different sheds?

You can't do that. But I don't have a bunch of different sheds in the same environment, and I don't see why you'd want to either. I can imagine having different sheds for different environments (different stuff for base Mac, Linux, and Windows systems, or for venvs targeted to Gtk+ vs. PyObjC vs. Flask web services, or whatever), but I can't imagine wanting to install 7 other people's sheds all at once or something. If someone else's shed were useful enough to me, I'd either merge it into mine, or suggest that they clean it up and put it on PyPI as a real distribution instead of a personal shed (or fork it and do it myself, if they didn't want to maintain it).

It's really not much different from using .emacs files (except for the added bonus of being able to pull in dependencies from PyPI and GitHub automatically). I used to look around dotfiles for ideas to borrow from other people's configs, but I never wanted to install 3 .emacs files at the same time.

> I don't want it to just overwrite my scripts when
> somebody updates their repository.
> 
>>>> ??? What if you have two shed repositories with different tools?
>> 
>> ... which solves that problem.
>> 
>>> I prefer to operate out of ~ so I'd symlink, but otherwise, yes. And
>>> there won't be two sheds, because there is only one me.
>> 
>> ... even if someone figures out how to fork and clone Chris or Anatoly.
>> 
>> Anyway, it works for me a lot better than the floppy I used to carry around with abutils.py, .emacs, and half a dozen other files I couldn't live without on a new/borrowed computer.
> 
> There was no Python in my floppy universe. It probably appeared 10 years later
> when internet became more accessible and Google said they are hiring. =)
> 
> I am now more inclined that there needs to be a shed convention to gather
> statistical data on custom root level importable that may be handy for some
> kind of "altlib" distribution.

I doubt you'd find much of use. There are specialized communities that have a broad set of things usable to most of the community, but those communities already have distributions like Python(x,y) that take care of that. I can't imagine too many things that would be useful to almost everyone. Even obvious things like lxml (and even if you could solve release schedule and similar problems), there are plenty of people with absolutely no need for it, and it has external dependencies like libxml2 that you wouldn't want to force on everyone.

Also, I think this thread has shown that, even though the basic shed idea is pretty common among experienced Python devs, different people prefer different variations--whether to pip install or just clone into your venv site-packages, how extensively to make use of git features like submodules or branches, etc.

But maybe promoting the idea as a suggestion somewhere in the Python or PyPA docs would get everyone closer to a convention that would make it easier to track. I'm not sure where you'd put it or what you'd say; any ideas?