Latest mdpopups version is not available

[jwortmann]

ST build 4200, Package Control v4.2.4

There was a new release of mdpopups tagged ~15 hours ago https://github.com/facelessuser/sublime-markdown-popups/releases, but it is still not available via Package Control.
Even if I manually delete mdpopups from the Lib/python38 folder, Package Control still installs the previous version of mdpopups (4.3.3).

Usually it only takes a few hours for Package Control to see the latest package updates, so I assume this must be a bug here or some other problem. Or is just the crawler interval different (longer) for libraries?

---

By the way, the Package Control: List Available Libraries command seems to show versions of the libraries that are not available to the plugin host (mdpopups v5.1.0 on ST build 4200).

[michaelblyons]

It worked for me just now.

• ST4199 (should be the dev equivalent to 4200).
• PC 4.2.4
• I'm using the PCR channel.json, and that may be different from yours.

Up until this version, I think I had been getting a message saying that the Python 3.8 version wasn't available in the correct format (although that might have been related to another problem).

[deathaxe]

Libraries shipped via https://github.com/packagecontrol/channel are crawled daily at 11:50 PM. The release will be picked up tonight.

[jwortmann]

Alright, I'll be patient then.

[rchl]

But why are libraries not being upgraded locally on its own? I shouldn't need to trigger library update manually.
I have started ST today, after not using it for almost a week and I see a message in the console:

Package Control: Skipping automatic upgrade, last run at 2026-03-15 11:53:42, next run at 2026-03-15 19:53:42 or after

But mdpopups is not at its latest version (it's at 5.1.0).

I have made a fix for an issue like that before but it was closed with a note that it was fixed in latest PC (which I haven't verified in code myself).

[deathaxe]

Quoted message indicates update checks being skipped due to last ST startup and update check being performed within specified update period (8h by default). Timestamp of update checks is stored in Cache/Packag Control/last_run.json.

Following console output is from a ST instance, starting the first time after a week.

...

reloading plugin UnitTesting.plugin
plugins loaded
Package Control: The library "pygit2" is not available for Python 3.8
Package Control: Upgraded library "mdpopups" from 4.3.2 to 4.3.5 for Python 3.8
Package Control: All specified packages up-to-date!

mdpopups is upgraded automatically.

[rchl]

My log message indicates that the check was performed today, way after 5.1.1 was released. So I don't understand why it wasn't upgraded today.

[rchl]

Did some debugging. It's the "has changed" check that prevented the update:

Package Control: Unable to upgrade library "mdpopups" for Python 3.13 because files on disk have been modified:
/Users/rafal/Library/Application Support/Sublime Text/Lib/python313/mdpopups/init.py

But since I've seen this affecting many people already and causing issues, I wonder why is that logic there? Is it to make it more practical for library developers?

I feel like it would be better to have some explicit way of preventing updates. Like a PC setting called for example ignored_library_updates: [] or similar.

[deathaxe]

The original intend was ensuring consistency or accidental data loss. If this is causing issues, #1734 teaches PC to just ditch local modifications in favor of newer upstream libraries.

Developer can remove .dist-info directories to prevent automatic upgrades, so any sort of setting management is not planned.