Show HN: Lescript – Simple PHP client library for Let's encrypt
github.com
github.com
Hell why doesn't everyone follow this? Instead I see projects with five or more build tools needed to deploy a website.
A single small website depending on... PHP/MySQL (obviously), Symfony, composer, npm, grunt, bower, ant, vagrant, docker. And well, language dependencies not needed by the website itself, just for the buildtools: python, nodejs, ruby, java plus virtualbox for vagrant!
All of this for a setup that can be (with proper documentation) replicated by hand and from scratch in <10 minutes (Debian, not RPM-based crap). The fuck are you smoking, people? Took me even WITH documentation about all those build tools 30min to get running where a simple git clone should be all that's needed. Bonus side effect: if you need to hack stuff in your deps, it's easier to ship them in your repo than if you use composer and friends.
I'd coin a new term for this: tool-sturbation.
Even if structuring a project around the PSR autoloader adds a bit more complexity (probably little more than adding a namespace and moving everything into a folder) that's still preferable to the dark days when everyone just rolled their own autoloaders (if you were lucky) or you were expected to do it yourself (and then maybe everything gets wrecked because of a relative path somewhere in the mass of includes of includes.)
Oh yes, it does - SSH or other shell access, as well as the hoster allowing the server to connect to the outside Internet!
Both are not common, in fact many hosters firewall their hosts for outgoing connections to prevent spam, botnets etc.
Well you will also need composer for actual deployment.
> . It really shouldn't be a problem to have ssh/a working internet connection on your development box.
Ever worked at a BigCo where everything is firewalled and needs a proxy? Or no internet at all and you gonna transfer stuff via USB sticks?
No you don't, it's PHP, there is no "actual deployment" beyond putting the files on a server.
Worst case scenario (because I've had to do this) is you have to change the paths in the file generated by the autoloader, if your development environment is different than production. But that's no more work than adding paths to include statements. You can even just do that locally first and move everything with FTP.
That's not really true. Even on our shared hosting platform (non-shell) we permit http/https/ftp outbound connections, and we're pretty conservative.
We also expect our customers to build and test their stuff locally then push up a working and hopefully error free site to our servers. We consider our servers production-only environments and will actually take you down if you're generating more than a few errors an hour, because errors and exceptions are expensive.
That said I do kind of agree with your sentiment about some "simple" projects that use everything under the sun just to get a todo list app built, even on my local dev env.
In fact we used to do something rather similar at my job, until we just switched to replicating containers over all our servers
Whoever wish to include manually this package and use it like if it was 1993 will still be able to do by cloning this repo and including the file by hand. On the other side, 99% of the sane PHP that has been written in the last few years including fairly large projects, WILL use composer to manage external dependencies as it's probably the single project who made PHP a modern language.
So, what are the cons of releasing this as a package?
I'm not even starting the conversation where I'm trying to convince you that using a dependencies manager is always a good thing to keep the codebase sane and clean - even for small scripts. That "<10 mins thing" is an empty claim as you have to do a boilerplate once and can use it all the time (unless you are the kind of programmer who is not 'good-lazy' but rather 'bad-lazy' and love to re-do its job by hand over and over)
of course, people don't have the bucks to shell out for that. I get it.
they don't know better. Don't forget what the base of most Wordpress and Drupal setups is - people with barely enough skill to do a FTP push, download and install a theme from Themeforest and done.
or they can't pay because nearly every US startup/service accepts credit cards only (which is not widespread in Europe) and no one really trusts Paypal.
Considering the audience of HN, I am astounded by the amount of people who complain about a PHP package being on Composer, yet they all use NodeJS, Go, and other things that require more than modern PHP and Composer does.
A managed hosting company does something important for you. They manage!
For the average user, this is something they need if they want to start a small business or a website for a project and want to have SSL while doing so. Integrating this with some form of tutorial for the average user makes this tool amazing.
I don't have reliable information about the market situation, but i assume that this is pretty much standard with shared hosting.
If your target host is *nix, develop on something unix-like.
Well. If you do it by hand you know WHERE and WHY it didn't work in case problems arise. Granted, it takes experience in server management, but imho a good developer MUST know about the platform his software is to run.
The more tools you add to the process, the more complex debugging gets when even the tiniest dependency chanes.
A single PHP file is the perfect solution to this. Call it from /etc/crontab and you are done.
I hate overladen projects on GitHub with all kinds of fluff. A single source file and a readme is just awesome.
Since you have to write a new PHP file anyway, composer allows you to pull in the latest version (or update it) with semver constraints.
Then you can package it as a phar and call it that way.
This is a library, not a file to run, and so it should have composer support.
Or, if you don't want to package it as a PHAR - since I have no idea how to do that, you'd implement your version in some directory and probably alias a command to it.
TL;DR: This is a library, not a script. It should have composer support.
You don't have to. Composer allows you to pick a particular package version if you like, and it's only going to fetch a more recent version if your composer.json permits it and if you explicitly run composer update.
On the other hand, what if you have a slightly more complex system with some logic to handle crons?
Though I notice that the README states "[i]ts goal [is] to have one easy to use PHP file without dependencies", and they point out there's already a proper package out there, kelunik/acme. If the goal is a single file with no dependencies, I can understand the lack of Composer, as it's not really targeted at that audience.
Completely agree with the namespace. You HAVE to namespace it :) Hope it helps
Hopefully the author sees it
I'm hoping to see a single file bash script at some point :)
Should this have an `array` type declaration? You used it on another function.
Ultimately services like LE will get to the point where certificates will expire in hours rather than days, so a problem like Heartbleed will 'self-heal' because certificates can be fixed and servers will automatically get the patch within a day.
This is correct.