cybercog / laravel-paket Goto Github PK

Catch Laravel app JobHasBeenTerminated event in VueJS app to unlock UI.

Introduce enumerable statuses for the Job entity.

Possible namesapce candidates:

• Cog\Laravel\Paket\JobStatus\Enums\JobStatus
• Cog\Laravel\Paket\Job\JobStatus\Enums\JobStatus
• Cog\Laravel\Paket\Job\Status\Enums\Status

Add refresh button to the app header.

https://github.com/sarfraznawaz2005/composer-cost

Need to refactor Composer support class methods install & uninstall. They shouldn't know anything about Job entity.

executeCommand doing too many things. It's doing JobFileRepository work. Maybe it will be better to make a new ProcessFileRepository class which will be responsible for process output read\write.

My idea simple in many cases you want see what happened on remote location while the dashboard in local or someware else it bit poinless the dashboard if you can setup remote monitor but love the idea

I want to have source repositories management tool inside of the Paket.

https://getcomposer.org/doc/04-schema.md#repositories

Add, remove & reorder repositories will have breaking changes and should to be implemented in next major version. For now we can release only list of repositories.

This feature will require to improve Jobs #3 at first.

Current API

To install requirement we can send POST /requirements request:

{
  name: "cybercog/laravel-love",
  version: "^7.1",
  isDevelopment: false
}

To uninstall requirement we can send DELETE /requirements/{uid} request, where {uid} is base64 encoded package name.

New API

But in fact we are not creating requirement. We are asking server to create a job to install this requirement. It might be better to have unified API endpoint to create all types of jobs.

To install requirement we will send POST /jobs request:

{
  type: "RequirementInstall",
  requirement: {
    name: "cybercog/laravel-love",
    version: "^7.1",
    isDevelopment: false
  },
}

To uninstall requirement we will send POST /jobs request:

{
  type: "RequirementUninstall",
  requirement: {
    name: "cybercog/laravel-love",
    version: null,
    isDevelopment: false
  },
}

• NullProcess - for the cases when process not yet launched and doesn't have any output and no exitCode.
• Process - for the cases when process executing but not yet completed
• TerminatedProcess - for the cases when process has been completed

Current Process could become AbstractProcess class.

Need to be able to terminate and delete jobs in Laravel Queue from the Paket.

does your package not support php 8?

[InvalidArgumentException]
  Package cybercog/laravel-paket has a PHP requirement incompatible with your PHP version, PHP extensions and Compose
  r version

some times the composer commond not in

/usr/bin

,such as. in mac or other linux os dont have permission to write，so often we put the composer in

/usr/local/bin

consider removing the definition of path and switching to the definition of environment path or any other better choice ?

Refactor API to satisfy https://jsonapi.org/ specification.

We can implement it with polling /api/jobs/{job} because it's local development machine and there is no need to worry about server load.

Before 1.0 release we must have mechanism to protect production applications from developers mistakes.

• requirement could be added to composer.json without --dev flag
• requirements could be installed on production without --no-dev flag

By default Paket should be available on local environment only.

This behavior could be configured in config/paket.php file paket.middlewares key.
Authorize middleware class is responsible for this restriction.

You may export configuration file using the php artisan vendor:publish --tag=paket-config command.

https://github.com/afterflow/workbench

There are many names: Job, Task, Process, Process Group, what are they?

Process - a process is an instance of a program that is being executed. In some systems it's called Task. When we are trying to install or uninstall requirement - we are running OS process via Symfony\Component\Process\Process. It might possible that installation & uninstallation will require to run multiple processes one by one, so we need to aggregate processes to a group.

Linux shell creates a process group for each Job it launches, and places each process it starts into the appropriate process group. For example, ls | head is a pipeline of two processes, which the shell considers a single job, and will belong to a single, new process group.

To not over-engineer system at this stage we will have Job entity, which have only one Process for the sake of simplicity. In next versions we should revise need of ProcessGroup aggregate.

Usage of word Job might confuse developers because Laravel uses it for Queue Jobs. To avoid confusion jobs on framework side will be called queue jobs and will be placed in \QueueJobs\ namespace.

Paket Job Runner will be located in queue job Cog\Laravel\Paket\Job\QueueJobs\RunJob.

Lock UI INSTALL & UNINSTALL buttons if there are any RUNNING job in list.

Sometimes composer missing new line breaks in output. Need to find a way how to fix it.

Current implementation

• Cog\Laravel\Paket\Http\Controllers\Api\Jobs\Collect\Action
• Cog\Laravel\Paket\Http\Controllers\Api\Jobs\Collect\Request
• Cog\Laravel\Paket\Http\Controllers\Api\Jobs\Collect\Response

New implementation

• Cog\Laravel\Paket\Http\Controllers\Api\Jobs\CollectAction
• Cog\Laravel\Paket\Http\Controllers\Api\Jobs\CollectRequest
• Cog\Laravel\Paket\Http\Controllers\Api\Jobs\CollectResponse

Current

Now we have 2 types of requirements depends of usage purpose:

• Root Requirement — package required for development & production.
• Dev Requirement — package required for development purposes only.

And 2 types depends of package is required as main functionality or is required by requirement:

• Essential Requirement — fundamental application package requirements.
• Dependency Requirement — a package required by other packages to be installed (because they relies on functionality provided by it).

But I've started to think that I've named it wrong.
Root Requirement should become Essential Requirement and vice a versa.

New

Now we have 2 types of requirements depends of usage purpose:

• Essential Requirement — package required for development & production.
• Dev Requirement — package required for development purposes only.

And 2 types depends of package is required as main functionality or is required by requirement:

• Root Requirement — fundamental application package requirements.
• Dependency Requirement — a package required by other packages to be installed (because they relies on functionality provided by it).

Need to revise relation between Job & Requirement entities:

• is Requirement belongs to Job?
• can Job accept null instead of Requirement?

It looks like I'm missing one more entity which links Job & Requirement entities.

Pretty cool idea from @barryvdh for Laravel Telescope: laravel/telescope#729
I think it will be good to add something similar later.

Some packages requires to run additional commands after installation process.

Nice little package! Love it so far :)

But we could improve the layout a bit. It always works better when the design is more coherent.

I have roughly prepared a draft for the dashboard and the simple requirements page. Tell me what you think about it :)

I would agree to make the implementation in Vue, if you want. But would rather do it on the side, so it might take a while for me.

Current API:

public function store(JobContract $job, RequirementContract $requirement): void

New API:

public function store(JobContract $job): void

Should we keep using cybercog/laravel-paket or switch to new cog/laravel-paket namespace?

No. We can't do it:

The vendor is already taken by someone else. You may ask them to add your package and give you maintainership access. If they add you as a maintainer on any package in that vendor namespace, you will then be able to add new packages in that namespace. The packages already in that vendor namespace can be found at cog

Otherwise developer wouldn't understand why job isn't starting. This info should be in Environment section of the Dashboard & displayed as warning icon in the top menu.