ASF GitHub Bot commented on PIO-47:

Github user dszeto commented on the issue:

    @pferrel For `pio build` we probably can enhance it such that it can take a 
working directory for compilation to run. If we look at some other build tools, 
they also rely on having certain files in the current working directory.
    For `pio train` and `pio deploy`, I absolutely agree that it should be able 
to run from anywhere as the most advanced scenario. My personal take to this 
change would be something comparable to a local HBase and distributed HBase 
setup. It would be ideal if someone can start playing with PredictionIO without 
setting up any external services (not even a SQL database). I believe Chan's 
change here is a partial step to make the learning curve less steep, and path 
ways for us to untangle engine registration so that it could become a feature 
that can be more easily documented and understandable.
    Do you currently have any production deployments that rely heavily on 
engine IDs and versions? That would be a bigger immediate concern regarding 
this change.

> Remove engine manifest for stateless build
> ------------------------------------------
>                 Key: PIO-47
>                 URL: https://issues.apache.org/jira/browse/PIO-47
>             Project: PredictionIO
>          Issue Type: New Feature
>            Reporter: Chan
> As discussed in the dev mailing list, removing engine manifest would be the 
> first step in improving the workflow towards a more modular design. 
> - Remove manifest.json completely. `pio build` will be stateless, and will 
> not write anything to the database. This will make it easier to compile/build 
> on PaaS platforms such as Heroku. Later, we can remove `pio build` command 
> entirely, so that PIO is independent of the build tool (sbt).
> - An immediate major disadvantage would be not being able to run pio commands 
> outside of the engine directory. This can be resolved in the next step of 
> creating a general metadata registry.
> - Meanwhile, we can use engineFactory as *engineId* , and SHA-1 hash of 
> engine filepath as *engineVersion* (as before). We can improve this when 
> designing a metadata registry, 

This message was sent by Atlassian JIRA

Reply via email to