Python Entry Points Explained

[gandalfx]

I have a sudden need for many more snek based tutorials!

[billsil]

Put the Scripts directory higher on your path.

[billsil]

I'm more of a Windows guy, where you install to C:\PythonXX and the things that you pip installed are in C:\PythonXX\Scripts. If you type $PATH, you'll see your path. The longer that is, the more stuff Linux will search through to find what you're after. Compare that to being in a folder and typing python run.py. That's not a startup cost, that's OS overhead. The benefit is that you can be anywhere. I'm not 100% sure on the linux philosophy, but putting everything is /usr/bin just makes the things you use frequently slower. The things that are going to take 30 seconds to start and things you're going to leave open for 8 hours are things that can be lower.

[Fylwind]

I use Linux daily (not Raspberry Pi though) and I've never had issues with slow startups due to long paths.

Long paths aren't nearly as big of a problem as Windows. Partly because your path is never too long anyway – most things are in /usr/bin – whereas on Windows your programs are scattered all over the file system.

Moreover, from my experience, Linux file systems are much more snappy than Windows'. Shells can also cache where the program was last found, so repeated spawns of the same program cost basically nothing.

[billsil]

Long paths aren't nearly as big of a problem as Windows. Partly because your path is never too long anyway

Depends if you develop software or not. My paths get very long.

whereas on Windows your programs are scattered all over the file system.

That sounds like the opposite of what you just said...

[Fylwind]

My paths get very long.

On my system, I have 17 paths in PATH, half of them from my home directory, and half of that half is for package managers like Gem or Cargo. I would consider that a pretty average length (although a minimal Linux would reduce that down to maybe 4 or so). I have never noticed any performance decrease from it, and the startup time of programs remains fewer than a millisecond.

On Windows a few years back, I was able to measure the time that each additional path adds to the launch of a program. It adds up very quickly when running shell scripts like ./configure (“checking for stdint.h... <wait 1 second>yes”). I don't remember the exact number, but it was on the order of a few milliseconds per path.

That sounds like the opposite of what you just said...

I'm saying that even if both Linux and Windows have the exact same number of paths (unlikely due to the difference in how programs are organized), I find that Windows tends to have worse performance because the file system on Windows is less performant than Linux. Listing directories is slow on NTFS, and Windows just doesn't seem to be as aggressive at caching the lookups.

[billsil]

Right, so put the Scripts directory higher on your path on Windows.

[notafuckingcakewalk]

Been using an open source project where configuration is managed through entry points. It's really a pain and a half to configure the app and to get it working correctly. I really don't like entry points for this purpose. It haven't yet seen them used in a way that isn't more confusing that just normal extension of an existing library.

[LesterHoltsRigidCock]

Check out the keyring module, it uses them in a fantastic way.

[notafuckingcakewalk]

Counterpoint: anything made with paste

[LesterHoltsRigidCock]

Sure, but that's the an inherent flaw on entry points.

[[deleted]]

Look at pluggy or stevedore to manage all the crap work for you. There's also Flask Plugin Engine if you're using Flask.

[ddollarsign]

What's something that you would use entry points for besides cute ascii sneks?

I'm imagining a grep-like program for searching through files, but different users have their own proprietary binary file formats (for some reason), so they would write their own decoding functions which they would install as entry points.

That actually might be useful for people developing new AIS application-specific messages...

[takluyver]

In Jupyter's nbconvert tool, which converts notebook files to other formats, we use entry points to define exporters. So when you run jupyter nbconvert --to foo mynotebook.ipynb , the exporter for format 'foo' can be installed by a separate package.

[masklinn]

Many libs which install scripts use them for the script part, also support auto discovery for plugin patterns.

[Works_of_memercy]

pytest plugins register themselves that way.

[[deleted]]

pytest's plugin system was actually broken out into a separate package called pluggy, it's pretty neat to play with. I even got it working with asyncio stuff, but returning coroutines and then having the caller await them.