Composer Package

[joseym]

Would be awesome if this were available as a composer package.

[javiereguiluz]

I'd also like to use php-markdown library as a composer package. Currently, the only available package is a stripped port of php-markdown: http://packagist.org/packages/dflydev/markdown

Creating a package is as easy as adding the following composer.json file in your project and submitting it to http://packagist.org website:

{
    "name": "michelf/php-markdown",
    "type": "library",
    "description": "PHP Markdown",
    "homepage": "http://michelf.com/projects/php-markdown",
    "keywords": ["markdown"],
    "license": "BSD-3-Clause",
    "authors": [
        {
            "name": "Michel Fortin",
            "homepage": "http://michelf.com"
        },
        {
            "name": "John Gruber",
            "homepage": "http://daringfireball.net"
        }
    ],
    "require": {
        "php": ">=4.0.5"
    },
    "extra": {
        "branch-alias": {
            "dev-master": "1.0-dev"
        }
    }
}

[sandeepshetty]

+1 for making this a composer package. In the meantime here is how I use it with composer:

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "michelf/php-markdown-extra",
                "version": "1.2.5",
                "dist": {
                    "url": "http://littoral.michelf.ca/code/php-markdown/php-markdown-extra-1.2.5.zip",
                    "type": "zip"
                }
            }
        }
    ],
    "require": {
        "michelf/php-markdown-extra": "1.2.*"
    }
}

[mauris]

@michelf Michel please take a look this issue. Over at dflydev's "fork" of your markdown classes, @simensen has done a great job in providing Composer integration and PSR standards compliance.

I am proposing new changes to bring development between dflydev/dflydev-markdown and michelf/php-markdown together and provide ease of integration into end-user projects through Composer.

I urge @michelf to take a look at the lengthy discussion developers have made about helping your markdown classes to be a great plugin and library for reusability. See dflydev/dflydev-markdown#5

It's good except for the strange use of lower-case. But yes, with @michelf
rather delaying that is a simple task, others are just going to pick up the
ball on this.... and have it seems.

[mauris]

@Drak - take a look at my pull request. I've made changes to ensure full PSR-0 and PSR-1 compliance.

If @michelf doesn't respond by 22 Dec 2012, I'd make a fork and merge the two projects into one.

[michelf]

@thephpdeveloper I have somme difficulty discussing what you're proposing at dflydev/dflydev-markdown#5. It seems like a grab bag request, encompassing many different things should probably be discussed independently one of another. For instance, I'm not going to switch to PHPUnit (I'm currently using MDTest).

@dark Making it a composer package might be a simple task, but I want to familiarize myself with how that works first. I'm the one who'll get support requests by email if things don't work right for someone. Also, I'd rather wait a little to make sure there's nothing I want to change in the packaging of the lib branch before offering everyone to switch to it by making it a composer package.

[mauris]

@michelf I'm very glad that you responded. I began to wonder if you had abandoned this project as this issue #31 was left hanging with no response from you for 7 months. Allow me to share with you there is way more than just PHPUnit you're missing out.

• Travis CI: continuous integration and automated testing. With this power of automation, I recommend you include your MDTest scripts and run it with Travis CI
• Composer: dependency manager for better release control and packaging for PHP
• Packagist: library submitted to Packagist for public listing so that developers can easily use Markdown parser by adding just one line into their Composer dependency file composer.json
• Namespace: You'll have better namespace management
• Object Oriented Abstraction: an interface would do great as it helps to decouple

You should look at this as a 2.0 release and channel your support request to Github Repository Issues so that more developers can participate and help you along the way.

The point about Open Source Software Development is not to just show your source code. OSSD is about people coming together to solve a problem and that more and more people can come in and sustain the project together. That's how OSS works.

If you need help on Composer, you can take a look at the slides I've created and presented over at SpeakerDeck: https://speakerdeck.com/mauris/introduction-to-composer-dependency-manager-for-php

Yes current users of your legacy markdown classes may not be able to receive updates when we upgrade, but it's time to let go and move on. We need to make great libraries like what you @michelf have created sustainable and friendly for developers.

I have watched many libraries die off because no developers were able to update them and upgrade processes were tedious. Composer has already made it much easier for developers to update their project dependencies already, so why re-invent that wheel.

I sincerely hope that this will help you better to understand the concern I have for this great project.

[mauris]

By the way, I couldn't find documentation for your MDTest. While MDTest may be more suitable to test Markdown processing, other developers may not be able to access your custom test. Providing a PHPUnit test may offer some comfort and better stability.

Please enlighten me if you do have documentation for MDTest. Thank you.

[michelf]

@thephpdeveloper https://github.com/michelf/mdtest

Also, many of the things you're suggesting are already implemented one way or another, are already in the works, or being planned. Look at the various open issues around here to get an idea. I'm sorry if things are moving slowly, but I have very little time to devote to PHP Markdown these days.

If you have other improvements to suggest, please open separate issues or pull requests.

[joseym]

@michelf

I'm the one who'll get support requests by email if things don't work right for someone. Also, I'd rather wait a little to make sure there's nothing I want to change in the packaging of the lib branch before offering everyone to switch to it by making it a composer package.

The great thing about composer classes is after you add the composer.json file, you submit the current repo to packages. They give you a key that you plug into github and then any changes you push are automatically reflected in the composer package.

You can define which branch, tag, hash, whatever you want composer to use so if you think you'll be branching off in a different direction you're able to tell the package which direction you're currently supporting.

Then for anyone to use your classes they just run php composer.phar update. All it really does is allow your project to be automatically included in other developers work.

[mauris]

@michelf with composer, you no longer have to manually zip up and upload your zip file for others to download. They can download easily through Composer, and it provides updates from your git repository through version tagging

[joseym]

@michelf I think what @thephpdeveloper and I are trying to say is that implementing composer doesn't mean you have to manage extra code or repos, it's runs behind the scenes and makes code distribution easier and more conventional. You can still manage this github repo, create tags and distribute the handy github archive links all the while packagist is tracking the project and ensuring that whatever version you've linked it to stays up to date so developers embracing composer can integrate your project into theirs without any hassle or additiona code management.

Cloning is sloppy, submodules have their place but are also fairly sloppy. Both require effort to ensure they stay updated with newest versions. Composer takes that effort away.

[mauris]

@joseym indeed.

@michelf We're trying to help you automate things so that you don't have to manage this repository so much. Let the OSSD ecosystem take charge.