Author: masnun

Categories
Mac Python

Setting up Python, MySQL Module and Django on Mac OS X Lion

I setup Python and Django using homebrew the easy way. I am going to detail the process now.

Install Python

The command should first install any dependencies for Python and then install the latest version from source code.

Adding Python to PATH

We need to edit our ~/.bash_profile to add “/usr/local/share/python” to the path variable. I added the following line to my bash profile:

I reloaded the profile by issuing:

This makes the python tools and toys accessible from my terminal.

Install MySQL Module

It’s recommended that you already have “mysql” installed from brew to build the mysql module. I already had it installed so it was a painless installation for me. I just issued the command:

Install Django
I am going to keep using the PIP awesomeness! Let’s hit:

It will install django with any dependencies. You can now invoke the “django-admin.py” command from your terminal. However, I prefer the command be “django-admin”, instead of “django-admin.py”. So I created the following alias in my ~/.bash_profile:

Isn’t it simple? 😀

Categories
PHP

Composer & Packagist: Painless Dependency Manager for PHP

URLs:
Packagist: http://packagist.org/
Composer: http://getcomposer.org/

Composer is a painless dependency manager for PHP. If you have used the conventional PEAR packaging system, you have probably felt the pain already. Composer came to our rescue.

Getting Started with Composer:
Follow this link to get yourself introduced with Composer: http://getcomposer.org/doc/00-intro.md

In short, you declare the dependency of your project in a file named “composer.json”. Then run “composer install” on the terminal. Composer will install the dependencies and provide you a single autoloader file which you can require in your project and start using the libraries/tools etc.

I recommend installing composer into your own “~/bin” so that you can quickly access it from any place. Use these commands to achieve that:

Of course, I assumed that you already have a “~/bin” directory created and the path is in your bash profile or bash rc.

Packagist: Creating packages for Composer
(1) You must have a public repository of codes to prepare a package for packagist. The code repo should be in Subversion, Git or Mercurial.

(2) Create a composer.json in your package’s root directory. It is a good idea to use:

The prompt will help you get started with a basic skeleton.

(3) Add more metadata to the package by adding different fields to the composer.json file. You can read about all the available fields here: http://getcomposer.org/doc/04-schema.md

If your package depends on other packages, do mention them on the file. Also if your package needs certain PHP extension, use “ext-*” format. Like – “ext-apc” for apc extension, “ext-curl” for curl etc.

Do not forget to use the autoload feature. Define your PSR-0 or conventional autoloading pattern so that your package can be easily used with the Composer autoloader. Look into the “autoload” part of the schema for more details.

(4) After you have finished editing the composer.json file, validate it by running:

This is step is very important. If you have any error in the json document, packagist will not be able to parse your package. For now, there is no notification system for such failures. So you better validate before you publish the codes.

(5) Create an account, login to packagist.org and submit your package. Packagist allows convenient hooks for auto updating to your recent branches.

(6) Package versioning is dependent on the tags of CVS. Name your tags in “X.Y.Z” or “vX.Y.Z” format. Eg. “1.0.3” or “v1.0.3”.

Demo:
You might want to examine these works for digging deeper into composer and packagist –

PhpTube Package: http://packagist.org/packages/masnun/phptube
Github Repository: https://github.com/masnun/phptube

Categories
Uncategorized

Tagging in Git: Why? How?

Why use Git tag?

Git tags are like milestones, markers or a specific point in the repo’s history marked as significant. Tags are usually used to mark stable releases or achievement of very important milestones.

Tags can help the users of the repo to easily navigate to the important parts of the code history like release points. For example, on Github, you can easily grab archive of “tags” in the current repo.

Dealing with Tags

List tags:

Search in tags:

That will display tags starting with “v1.” – use regex and your common sense to do complex queries. This can help you narrow down your query in case you have plenty of tags in the repo.

View a tag:

Note: The command doesn’t have “tag” in it. 🙂

Adding tags:

The “-a” denotes an annotated tag – means it’s stored as a full object in the git database where as a non annotated tag is just a pointer to a specific commit. Just drop the “-a” to create normal tags. The “-m” option is of course obvious, it allows you to add a message to the annotated tag.

Adding Tags later:

This will add the “v1.2” tag to the commit marked by “9fceb02”. “git log” will help you get the checksum of the commit.

Pushing Tags to remote branch:

PS: Git tags are not pushed automatically with generic “git push” command. You must push the tags separately.

Deleting a tag:

That will delete the tag v1.0.0.

These are the very common uses of Git tags. Look at the git manual for more complex stuff you can do with tagging 🙂