Fix ImportError for markdown.inlinepatterns

[LorenzoAncora]

Fixes: ImportError: cannot import name 'ReferencePattern' from 'markdown.inlinepatterns' ...which happens when Markdown > 2.6.11 is automatically installed. In addition, ensures the project home page is visited only via HTTPS.

[LorenzoAncora]

@jandecaluwe this fixes #81 and #77.

[josyb]

Hi Lorenzo,

I would rather see the codebase updated to work with MarkDown 3.1.0

Regards, Josy

[LorenzoAncora]

I would rather see the codebase updated to work with MarkDown 3.1.0

Hi @josyb, I would like too, but Markdown 3.0 implemented many breaking changes ^0 which require a small refactoring of the codebase, task which is better fit for the original author or for whom works in his behalf. In the meantime maybe it would be wise to merge this PR to prevent Urubu from crashing with mistery errors when people try to use it. At last, this also eases the deployment in virtualenv.

[josyb]

Yes, code-breaking is the open-source community's favorite pastime :( I have never used, and probably will not, virtualenv; once you go down that rabbit hole ... So I downgraded my installation system-wide to MarkDown 2.6.11

[LorenzoAncora]

@josyb thanks for merging,

Yes, code-breaking is the open-source community's favorite pastime :( I have never used, and probably will not, virtualenv; once you go down that rabbit hole ...

There was a time by which I had the same idea, but then the actual practice made me realise mine was a superficial thought. The main purpose of virtualenv and the like is to avoid code-breaking, and in particular conflicts of dependencies. This is not easy to understand, so I'll do a quick example:

• the system has Markdown 2 installed;
• system software A can be installed via package manager and requires Markdown 3;
• system software B can be installed only via tarball requires Markdown 2;
• user software C can be installed via pip and requires Markdown 3.

The system administrator needs to install A and B and one user (ie. an executive) wants to use C, which must continue to work regardless of what happens to the rest of the system. In this situation, the sysadmin will;

1. upgrade the system Markdown to the latest available (ie. 3);
2. install A via package manager;
3. create a virtualenv and install B in the system src/ directory;
4. install Markdown 2 in the virtualenv of .3 and create the appropriate shortcuts so end users can execute B from an icon;
5. create a virtualenv in the executive's home (eg. in .local) and install via pip both Markdown 2 and C;
6. create the appropriate shortcuts to start C from an icon, only for the desktop of that user.

This way the problem is solved without virtualisation nor performance degradation: the system uses the latest version of the dependency and the old applications use only the old version of the dependency, thus preventing conflicts and security issues. Obviously, this works only if the sysadmin understands virtualenv and is meticulous enough to maintain each virtualenv up-to-date in relation to the need of each "isolated" application.

I downgraded my installation system-wide to MarkDown 2.6.11

…this is fine on systems which do not have web applications exposed publicly and do not have installed applications which require different versions of Markdown. If, one day, you need to expose a web service which might use Markdown, remember to secure your system by installing the latest version system-wide and create a virtualenv for Urubu (and in general any other software which requires Markdown 2). Otherwise, if you really hate virtualenv and system resources are not an issue, classic virtualisation is also an option.

Btw, if at any time you need a new lead developer for Urubu, feel free to drop me a message. :-)

Take care, Lorenzo

[josyb]

Hi Lorenzo,

My rant still stands; if code was not broken we wouldn't have dependency issues. Using virtualenv to mitigate that code breaking is what I would call a stopgap. And because you now have virtualenv the developers don't have to hold back - the user will, has to, deal with it. I maintained a small API for our CMOS camera series for over 15 years without breaking code; if absolutely necessary I just did like Microsoft and added a 'Ex' to the function name when expanding the calling arguments. As a result the youngest .dll would still work with the oldest .exe. Again, it was a reasonably simple API. Luckily, as a hardware engineer, I don't face the issue that often: 1) I am a one-man band working solo, mostly developing FPGA logic code using MyHDL. 2) Windows user (yes, you may frown) because in the days all EDA was on Windows only - It may never be too late to switch camps. I once tried but on Linux I had to look up every command. I might try again once I am fully retired. 3) And do all my work mostly inside Eclipse (frown again?): VHDL, Python, MarkDown, Impulse wave viewer, XML, ... So after all not too exciting.

Btw, if at any time you need a new lead developer for Urubu, feel free to drop me a message. :-)

I will be glad to merge your artful PRs. You can perhaps send your letters of credence to the OA: Jan Decaluwe. He might grant you full access rights.

Regards, Josy