have drush make use the pm primitives

I'd like to see this. Note that drush updatecode does require a drupal install and update module. But drush dl requires neither. Lets put the best code we have into drush core for calculating best release, downloading via wget/curl/cvs, and so on. Patches to drush core are always welcome.

I'm quite open to putting all of drush_make into drush core, when you guys think it is time. Lets discuss.

First, GREAT module that standardizes what I suspect many have been creating in a non-standard way. Really enjoying playing with it.

It occurred to me when submitting a patch for the curl part of drush_make that it didn't make sense to have the wget, curl, etc. code in drush_make when drush dl would do the same thing. (Am I missing something as to why drush_make has that? Is there something drush dl doesn't do that's required?).

The power of drush_make is (or could be) parsing of the .make file and applying it to drush commands. I've been creating bash scripts to do pretty much the same thing as drush_make config files and it has the added benefit of creating the database (if desired). Most everything is accomplished using drush commands already available. My sense is that drush_make could/should follow that model.

subscribe.

Let's get rid of this duplication once and for all.

Unfortunately, just as we never got to 1.0, I think that some major architectural changes (in a positive way) will make us (i.e. me) re-write major portions of the code base, so it might be better to just branch and call it 3.x.

Points of duplication I see:
-- Downloading projects: drush_pm_download() (the bottom of pm.drush.inc) looks too familiar. Let's start using that or write a patch to get it into a state where we can use it.
-- Objects for VCSs. Again, PM has these: version_control/(svn, bzr). PM doesn't do downloading from VCSes, it only does committing after downloading. We should be able to just add new methods into these objects (well actually, integrate our existing ones).
-- package_handler/(cvs, wget) - we have very similar code to this as well

I'm not sure where the code should end up. Since some of it will be used by drush, it might make sense to leave it there, however then there will be code in drush core that it isn't using.

Moshe mentioned the possibility of at some point putting drush make itself into drush core. In that case it would make sense for this code to live in drush.

Other notes for 3.x:
-- the queue goes. It's an unnecessary level of abstraction that confuses everyone (yes, myself included).
-- let's look into drush core's new 3.x awesomeness and see how much of that we can use.

Also:
-- Once we reduce d(r)uplication, we can start looking into integrating more with drush's guts. Imagine making a makefile on top of an existing site, which can download new modules as well as new version of modules and then updating its code.

I want to kind of shift focus and try to get a stable release asap. once everything actually works i'm going to try to make some progress on this issue.

I keep neglecting this issue but I want to use the critical status to keep track of what I want in the next beta.

Now that .download.inc is just about stable, I think we can take a look at this issue again.

Maybe the duplicated pm code should just be merged into drush 4 and removed from drush_make 3, but stay in (and therefore not block) drush_make 2?

Yeah, I'm just looking at smaller stuff for now, but that was/is the plan

I've been messing with drush make and drush dl/pm again today and came to similar conclusions. Would love to see this happen, and will attempt to help shed light on things that I have useful knowledge about in this space... If there are specific tricky things I can help with, let me know. Otherwise, I'll try to review/test patches when they materialize, but I sadly can't promise much bandwidth for that...

subscribing

Subscribe

Looking at the download code in drush 5 it is a lot more naive than that in Drush make. Drush make's looks at the headers for the HTTP request, and uses that to possibly rename the file to have an extension of 'zip', 'tar.gz' or 'tar', then these are used later for extraction.

Drush make's downloader is a lot more general than the one in Drush, which is very geared toward downloading Drupal projects and not random files from the internet. Potentially Drush make could be re-worked to use some of the low level plumbing that drush provides, but I don't think there's ever going to be the ability to call one of the high level Drush commands to download.

[ Powered by #1115636: Issue Macros and Templates - Drush Make]

Drush make is being merged into drush core (discussed in issue:#1310130: Put drush make in drush core)
This means that the issue queue is also moving. The Drush project has a component called 'Make' for this purpose.

We would like to take this opportunity to leave behind old/obsolete issues, allowing us to focus on a stable make command in core. E.g. one of the major tasks ahead is making more use of the Drush core code for handling downloads and decompression.

If you feel that this issue is still relevant, feel free to re-open and move it to the Drush queue.

More information will be posted on the drush_make and drush project pages.

I think this is still relevant - even though make is merged into drush, it still doesn't use the drush PM primitives, which can be a major source of confusion.

see #1267228: Drush Make should use Drush core's native download abilities concurrently

#698104: Cache downloaded files is duplicated of this